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ABSTRACT 


Software project development can be characterized as failing to meet the user's needs 
within budget and schedule limitations. The number of software development failures 
far exceeds the number delivered as specified throughout industry and specifically in the 
Department of Defense. The System Dynamics Model of Software Project Management is 
a sustained and generally accepted quantitative model for simulating the software 
development lifecycle. Dynamic management issues can now be evaluated in an 
experimental setting which eliminates the financial risks. 

The objective of this thesis is to use the System Dynamics Model’s gaming interface 
to investigate the effects of managerial motivation on software project managers in a multi- 
project environment. Specifically, this experiment was conducted to determine the effect 
of individual or team motivation on subsystem managers of a larger project. The effect of 
the two motivation methods are measured in terms of staffing level decisions, final cost 


and final duration. 
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I. INTRODUCTION 


A. BACKGROUND 

In a recent congressional report, eight major computer 
systems in the U.S. Department of Defense experienced a 
combined cost overrun of more than one billion dollars. 
Further, a survey of software applications revealed that 47% 
of the software applications were delivered and not used, 29% 
were paid for but not delivered, 19% were abandoned or 
reworked, and only 2% were used as delivered. In spite of 
best efforts to reverse the trend of software project 
development malaise, software systems continue to be delivered 
late with cost overruns, poor reliability and user 
dissatisfaction [Ref. 2: p. 1426]. [Ref. 1] 

The problem is compounded as the demand for software 
applications continues to exceed the ability of many software 
engineers to provide economical products on time that meet the 
user requirements. A conservative estimate indicates a one 
hundredfold increase in demand for software in the last two 
decades [Ref. 2: p. 1426]. There is little argument that 
technology has kept pace with the demand. Recent efforts for 
improving performance have shifted the focus from the 
technological production of the software application to the 


managerial operating process and environment involved. 


Managing software development is a very complex process. 
The software project manager must make decisions based on a 
wide variety of decision variables in an increasingly 
competitive environment of scarce resources. A major 
deficiency in much of the research to date on software project 
management has been the inability to utilize our knowledge of 
the microcomponents of the software development process such 
as Scheduling, Productivity, and staffing to drive 
implications about the behavior of the total socio-technical 
system [Ref. 2: p. 1428]. 

The Systems Dynamic Model (SDM) of Software Project 
Management represents a comprehensive model of the dynamics of 
software development [Ref. 2: p. 1426]. Through the use of 
the model, a wide range of managerial processes and dynamic 
operating environments can be simulated, tested and evaluated. 
The SDM has supported a stream of research into the 
implications of managerial decision making in software 
development projects. A stated benefit of using the SDM is 
the ability to examine the effects of changing one factor 
while all the other factors are held unchanged [Ref. 2: p. 
1433). The model was initially designed to evaluate such 
factors as the effects of staffing level decisions on the 
final cost and schedule in a single project environment. 
Subsequent enhancements to the model expands its capabilities 
from single project simulation to multiple project or 


subsystem simulation environments. 


This enhancement offers a rich opportunity to evaluate the 
dynamics of decision making in a multi-project environment. 
Using a number of project managers operating as pairs, data on 
many potential software project management concerns and 
general management theories can be evaluated. Such potential 
questions include: subsystems of a larger project with 
overlapping start dates, differing or competing resources, and 
changes in project size and/or complexity. Pert charts 
traditionally identify a single critical path; however, with 
modular software development there may be several critical 
paths depending on changes in a subsystem's complexity. The 
enhanced SDM might be used as an iterative process for 
optimizing this situation. 

An area of significant concern in a time of decreasing 
budgets and increasing oversight is managerial decision making 
with insufficient resources. An interesting issue is the 
motivation style employed to ensure the performance of two 
subsystem managers operating on a single project with a 
limited resource pool of staff. One alternative motivation 
method is to reward or compensate managers based on the 
performance of their subsystem. This puts them in direct 
competition with their counterpart. The other motivation 
method, in this case, is to reward or compensate managers 
based on the total performance for the combined project. This 
is "team" motivation versus "individual" motivation and is 


intuitively the preferred management style. The question is, 


does team motivation produce improved results as measured by 
the final cost and final completion date of the project as a 


whole? 


B. PURPOSE OF RESEARCH 

The purpose of this thesis is to design, construct and 
execute a multi-project management experiment, using the 
enhanced version of the SDM gaming interface. This experiment 
addresses the research question of the effects of managerial 
motivation on project performance. Even though "individual" 
versus "team" motivation has been explored in general 
management theory, it has not been formally tested with 
respect to software project development. A review of the 
literature with respect to competition and incentives has 
revealed very little research conducted to identify an 
acceptable experimental format under these circumstances. The 
software project management system is a far more complex 
conglomerate of interdependent variables that are interrelated 
in various nonlinear fashions [Ref. 2: p. 1427]. 

The SDM gaming interface is used to present management 
pairs with a standard interface to the simulation model. The 
managers are subject to either "team" or "individual" 
motivation and are required to make staffing level decisions 
through the design and testing phases of project development. 
Performance is measured in terms of final cost and final 


completion date of the total project. This data is analyzed 


using standard SAS procedures to determine the significance of 
performance deviation. Through this process, some light 
should be shed on management motivation in multi-project 
environments. 

Secondly, this thesis is intended to be a model for 
conducting experiments using the SDM gaming interface. The 
multi-project experiment serves as the context for presenting 
a sequential series of steps taken to design and conduct the 
experiment as well as analyze the data. In general, sections 
are written with the  methodology-specific information 


preceding the experiment-specific information. 


С. SCOPE OF RESEARCH 

The scope of this research includes the design, 
construction, preparation of documentation and software, 
execution and data analysis of the multi-project experiment. 
The design required an iterative process of diagraming, 
building and testing several potential models in order to 
identify the single independent variable that offered the 
richest research opportunity. The construction of the 
experiment required that the SDM model gaming interface be 
tailored for the specific research question. Special care was 
taken in the presentation of the interface and reports to the 
experimental subjects in order to prevent introducing any 
external biases that could affect the results. The 


preparation of the experiment entailed writing the 


documentation that each group used and finalizing the files 
required by each experimental group onto a single floppy disk. 
Each experimental subject was presented with an individual 
folder and any specific instructions. The execution of the 
experiment was organized to conduct and collect the data in a 
single day. This was accomplished with two groups of roughly 
thirty subjects each. Limitations оп scheduling and 
microcomputer resources dictated such careful planning. The 
analysis of the data consisted of analyzing the data with 
Quattro Pro spreadsheet software and SAS statistical system 


procedures. 


D. ASSUMPTIONS 

The subjects in this experiment were fifth-quarter (in a 
Six-quarter curriculum) graduate students studying in the 
Computer oystems Management curriculum at the Naval 
Postgraduate School. These same subjects participated in a 
Similar experiment using the SDM gaming interface during 
previous quarters. Although the subjects were not practicing 
software project managers, the amount of training completed in 
the curriculum and experience with similar software management 
experiments leads to the assumption that the results of the 
experiment and the conclusions would be represented in the 
software industry. This is also supported by the work of 


William Remus [Ref. 3:pp. 19-25]. 


E. THESIS ORGANIZATION 

Chapter II is a description of the software files and 
documentation design and construction considerations in 
preparing the experiment materials. The chapter also includes 
a section on conducting the trial experiment. Chapter III is 
an in-depth description of the methodology, sample population, 
and experiment organization required to conduct the 
experiment. Chapter IV  validates and analyzes the 
experimental results. Chapter V summarizes the significant 
accomplishments and implications of the findings presented in 
Chapters II-IV and provides recommendations for further 


research. 


II. PREPARING THE GAMING INTERFACE 


A.  EXPERIMENTAL DESIGN 

The Systems Dynamic Model gaming interface enables 
software management experiments to be designed which are 
Similar in many ways to the flight simulators that pilots use 
to mimic flying an aircraft from takeoff at point A to lanes 
at point B. Instead of flying an aircraft, though, WENN 
simulation mimics the life of a real software project from the 
start of the "design" phase until the end of the "testing" 
phase. Virtually any management concern or theory can be 
tested by designing an appropriate experiment and gaming 
interface. Figure 2-1 is a simple experimental design 
worksheet used to conceptualize many design possibilities. 

Exploratory experimental designs and test simulations 
using the gaming interface, as well as the ideas presented in 
previous research with the SDM gaming interface, provided 
several potential research questions. While a single research 
question was isolated for examination, some of the most 
interesting alternative questions are described in Chapter V. 

In a time of decreasing budgets and increasing oversight 
the richest research opportunity is managerial decision making 
with insufficient resources. An interesting issue is the 


motivation method employed to ensure the performance of two 


subsystem managers operating on a single project with a 
limited resource pool of staff. By imposing a restrictive 
workforce ceiling, real life concerns can be addressed. One 
alternative motivation method is to reward or compensate 
managers based on the performance of their subsystem. This 
puts them in direct competition with their counterpart. The 
other motivation method, in this case, is to reward or 
compensate managers based on the total performance for the 
combined project. This is "team" motivation versus 
"individual" motivation and is intuitively the preferred 
management method. The question is, does team motivation 
produce improved results as measured by the final cost and 
final completion date of the project as a whole? 

Figure 2-1 is the worksheet representation of the 
experimental design of this thesis. In this experiment, 
Subjects play an important role as the manager of one of two 
major subsystems that are being developed on a single project. 
Subjects were paired as the two subsystem managers for the 
project. Each subsystem manager was required to track the 
progress of his subsystem using a number of status reports 
that were produced at two-month intervals (40 working days). 
As the subsystem manager, the subject was required to 
determine and/or revise the staff size required for his 
subsystem at each reporting period. When entering staffing 
level decisions at each time period, subjects were required to 


coordinate with the other subsystem manager to ensure that 


their total staffing needs did not exceed the imposed staff 


level ceiling for the project as a whole. Each subject 
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Figure 2-1 Experimental Design Worksheet 


entered into the simulation his and the other subsystem 


staffing level needs. 


10 


Subject pairs were divided into two sets according to the 
method of motivation imposed. While the subjects were not 
monetarily compensated for their efforts, they were told that 
their performance would impact their assigned grade in the 
Software Engineering course they were taking. This ensured 
that the subjects provided a serious and diligent effort. One 
set was given written instructions which indicated that 80% of 
their compensation would depend on the performance of their 
subsystem with only 20% compensation for the performance of 
the overall project. This set із referred to as 
"Individually" motivated. The other set was given written 
instructions which indicated their compensation would be 80% 
for the performance of the overall project and only 20% 
compensation for the individual subsystem performance. This 
set is referred to as "Team" motivated. Pairs consisted of 
Player A and Player B, both receiving written instructions of 
the same motivation method. The performance of the "Team" 
motivated Player A and Player B pairs was compared to the 
performance of the "Individually" motivated Player A and 
Player B pairs. 

The independent variable is the method of motivation and 
the dependent variables include: final cost, final schedule 
and staffing level decisions. 

One experimental concern was that the pairs would simply 
compromise rather than compete for staff resources by dividing 


the available pool down the middle. This issue was resolved 


11 


by altering the dynamics of each subsystem. The Player A 
subsystem increased in number of tasks roughly double during 
the life of the design and testing phases. The Player B 
subsystem increased in complexity roughly double during the 
life of the design and testing phases. Each subsystem, 
therefore, experienced an increasing need for staff. Further, 
each subsystem was staffed with an initial core team of five 
people remaining at the end of the requirements phase. 

The result was four groups of subjects who received group- 
specific sets of instructions. The groups are referred to as 
"AI" (indicating Player A, Individually motivated), "AT," 
"BI," and "BT," as indicated in Appendix A. 

The experimental population had previous experience with 
the SDM gaming interface within the previous six months. In 
order to prepare the subjects for providing the best possible 
performance, each subject received an initial 30 minute review 
of the function of the gaming interface. During this initial 
review the subjects were reminded that a real project 
management situation did not provide them with absolute 
control over the work force level. Turnover, promotions, work 
force ceilings, transfers, hiring and assimilation delays 
prevent the manager from always getting the exact work force 
requested. Following the review session, each subject 
performed a "DUMMY" simulation on an individual basis. This 
design and documentation is discussed later in this chapter. 


The purpose of these training sessions was to eliminate any 


1:2 


ducomfort. unfamiliarity or bias that might be attributed to 
subject interaction with the gaming interface itself. Only on 
the day of the experiment were the subjects informed of the 
subsystem nature of the experimental task and that they would 
be paired with a randomly-selected counterpart. 

The DUMMY simulation was a SDM model named EXP1 based on 
an actual NASA experiment. Each subject played this 
Simulation as a single project, entering the desired work 
force level required. The input variable named WFNTR1(1) was 
transparent to the subjects. Each subject played the 
simulation for two forty-day time periods (80 days) to become 
familiar with the interface and then exited out of the 
program. 

The actual experiment was a SDM model named EXP2 based on 
an actual NASA experiment which has been used as the basis for 
several other research experiments. By using the real 
projects with real data, the results of the experiment can be 
measured, compared and validated against a known baseline. 
Each subject was required to enter, for each time period, the 
desired staff level for his subsystem as well as for his 
counterpart's subsystem. A simple computer algorithm 
prevented the subjects from entering a combined total greater 
than the imposed work force ceiling levels for the project as 


a whole. 
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B. THE SOFTWARE 

In order to conduct the experiment, two significant design 
and construction efforts were required so that the 
experimental subjects experienced the design outlined above. 
The first was the construction of the software which drives 
the computer gaming interface that the subjects used. The 
second was the documentation which explained to the 
experimental subjects the instructions, environment, task, 
rules and other considerations. This documentation was also 
used to capture in writing the desired staffing level 
decisions. 

The SDM model gaming interface includes the Dynamo 
Simulation files as well as the Dynex files which allow the 
model designer to interface with the Dynamo simulation 
language. The objective is to assimilate a set of files whose 
construction allows the novice user (experimental subject) to 
simply start and play the gaming interface with ease and 
without error. Further, the files must be designed in a 
manner which allows the designer to capture the raw data for 
further analysis. While the actual contents of the base file 
set may differ depending on the experimental design in 
question, there is a minimum of 13 files required to provide 
a format for a smooth gaming interface design. Figure 2-2 is 
the base file set used for this experiment. 

The Dynamo simulation model should be constructed, 


modified and maintained by a single project manager. This 


l4 


model controls all the dynamic variables which define the 
experimental setting. The base set files EXP2.DAT, EXP2.INS, 
and EXP.SMT are the minimum required files that define the 
project environment. The only limitation with these files is 
that all the variable names used with the remainder of the 
base set of files must be defined within these Dynamo files 


prior to their compilation. 


MOVE.BAT : Transfers output files to a floppy. 
PROJECT2.BAT : Control file for experiment. 

ВАТ. СОМ : Batch enhancement language. 
EXP2.DAT : Dynamo required data file. 

EXP2.DNX : Designer Dynex interface to Dynamo. 
EXP2.DRS : Output report specification. 
DYNEX.EXE : Dynex execution file. 


INFOOFB. EXE : C language data stripping file. 
INIT.EXE : C language initializing file. 

REP . EXE : Report generator execution file. 
SMLT.EXE : Dynamo simulation execution file. 
EXP2.INS : Dynamo required simulation file. 
EXP2.SMT : Dynamo required simulation file. 





Figure 2-2 Base File Set 


The language interface that the experiment designer will 
use to interact with the Dynamo model is called Dynex [Ref. 
ШІ. The Dynex file EXP1.DNX (filename.DNX) for the DUMMY 
Simulation is included as Appendix A, and the Dynex file 
EXP2.DNX for the experiment simulation is included as Appendix 
B. These files are written by the experiment designer and are 


plain ASCII text which can be edited with a favorite text 


15 


editor, even WordPerfect. Chapters 12 and 13 of the Dynex 
user's manual [Ref. 4] provide the basic instructions for 
constructing the Dynex file. The basic purpose of this file 
is threefold: to provide dialog to the user which identifies 
what the user needs to do to interact with the gaming 
interface, to capture the variable(s) required for the 
simulation, and to provide a report format for the output 
Screens. In the case of the DUMMY simulation the user was 
instructed to enter a single staffing level decision 
(WFNTR1(1)). In the case of the experiment simulation the 
user was instructed to enter the staffing level decision for 
Player A's subsystem (WFNTR1(1)) and Player B's subsystem 
(WFNTR1 (2)). In order to personalize and standardize the 
gaming interface for all subjects, the order of appearance of 
the variables in EXP2.DNX were ordered such that each player’s 
staffing level input was solicited first. The order of 
appearance of WFNTR1(1) and WFNTR1(2) in Appendix B reflects 
the Dynex file used for all Player A subjects. The reverse 
orde- was used for all Player B subjects. 

The Dynex file was further personalized in the reporting 
format of the output screen. Notice that each of the report 
variables appearing at the end of EXP2.DNX specify 1 in 
parenthesis corresponding to the use of WFNTR1(1) for Player 
A. Likewise Player B received a report output screen which 
specified only the variables corresponding to WFNTR1(2). This 


produced an output report at the end of each simulated time 


16 


period which showed only the status of the individual 
subsystem. In this manner, each subject was able to keep his 
subsystem status confidential. A sample output report screen 
is included as Appendix C. In addition to the output report 
specification at the end of the Dynex file, this output report 
specification also should be duplicated ina file by itself 
with a .DRS extension, as is the case with the base set file 
EXP2.DRS. This file is used by the Dynamo simulation model to 
specify and record the output format. 

The second file that is directly controlled by the 
experiment designer is the batch control file which controls 
the flow of the gaming interface. The file DUMMY.BAT is 
included as Appendix D for the DUMMY simulation and the file 
PROJECT2.BAT is included as Appendix E for the experiment 
Simulation. This is a standard batch file routine which 
controls the traffic flow while playing the game. The most 
noteworthy feature of these batch files is that they allow 
full use of the computer screen. Depending on the text editor 


used, this file may not reflect the true appearance of the 


screen until it is executed. Notice that the batch file 
controls the order of program execution, aS well ав 
controlling screen colors and menu selection options. The 


batch files used in this experiment were enhanced using the 
Extended Batch Language (EBL) to control menu selection items 
and appear in the base set of files as BAT.COM. While EBL was 


used in this experiment there are several alternative 


17 


utilities which provide similar features Figuttewp-3j3-m0 NE 


flowchart of the program and file interaction of the base set. 


| PROJECT2.BAT 
INIT.EXE 


BAT.COM 


/ EXP2.DAT DYNEX.EXE 


/ 


/ EXP2.INS REP.EXE 
¿= N 


/ EXP2.DRS 4 | INFOOFB.EXE 





Figurec2-3 Flowehart of the Base Filoz iE 


Two files essential to the execution of the simulation are 
DYNEX.EXE and REP.EXE. These files allow the execution of the 
Dynex file written by the designer and generate the specified 
output report format, respectively. The file SMLT.EXE is the 
primary Dynamo execution file. 

The remaining three base set files are not essential but 
make working with the raw data much easier. The first 1$ 
INIT.EXE, which is a C language program placed near the 


beginning of the batch control file. This small program asks 
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the experimental subject to enter his name and Student Mailbox 
Code (SMC). The program also captures the keystrokes that the 
subject enters during the course of the experiment which can 
be used as an audit trail. This data is deposited in a file 
called LOG1. The source code for this program is provided as 
Appendix F. The second base set file is INFOOFB.EXE, also a 
C language program, which reads the numerical data values from 
their video screen position and strips the data values from 
each output report screen. Appendix C is a sample output 
screen. This program reads the data displayed for each time 
period as recorded in the JUNK.OUT output file described 
later. INFOOFB.EXE can and must be specifically modified and 
compiled to match each text report used. The system designer 
should place the INFOOFB.EXE program call in the controlling 
batch file, just after the REP.EXE program call. This type of 
file can be used to record the output data from several 
different text report screens by modifying the source code 
(provided in Appendix G), changing the program name and 
changing the destination file name. This is a time-saving 
program which collects all the report data and deposits it 
into a file called INFO1. The third base set file is MOVE.BAT 
which is a simple batch file written to transfer the output 
files and the data files described about from the C: hard 
drive directory to a floppy diskette in the A: drive. The 


necessity for this file is described in Chapter III. 
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When the simulation is executed these 13 files expand to 
a total of 22. The additional files that are created by the 


Dynamo simulation are presented in Figure 2-4. 


INFO1 : Data stripped from INFOOFB.EXE 

LOG1 : Data recorded by INIT.EXE 

EXP2.CHG : Dynamo generated file. 

EXP2 .OUT : Complete report log. 

INTERVAL. : Holds the last report output screen. 


JUNK OUT ; INTERVAL.OUT, but Feeds INFOOFB.EXE. 
EXP2.RSL : Dynamo generated file. 
EXP2.STT : Dynamo generated file. 
EXP2.WAS : Temporary store for input variables. 





Figure 2-4 Dynamo Created Simulation Files 


The ІМҒО1 апа 1061 files are described above and are 
useful during data validation and analysis. А11 the .OUT 
files, including JUNK.OUT, provide the reported results from 
the output report screen. Depending on the research question, 
this information may be used to evaluate many alternative 
issues. The EXP2.WAS file temporarily records the Dynex input 
variable values of WFNTR1(1) and WFNTR1(2). During the next 
iteration, the Dynex file recalls these values and reports 
them as the last recorded entries. The new variable values 
replace the old ones. Appendix H is a copy of each of the 
computer screens, in sequence, which is the product of 
programming the software. These screens are the actual ones 


seen by the subjects during the experiment. 
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The software for the DUMMY experiment was designed and 
constructed to represent the experiment environment as closely 
as possible and still remain in a single project mode. The 
primary intent of the DUMMY simulation was to familiarize the 
subjects with the gaming interface. The experimentation 
interface differed only where necessary to facilitate the two- 


player option. 


C. THE DOCUMENTATION 

The documentation provided to each subject was an 
instruction set which described the purpose, scope, rules and 
procedure for the gaming interface. For the experimental 
subject, the documentation was the key link in achieving a 
clear understanding of his role in the experiment. For the 
researcher, the documentation served two very important 
functions: to give each subject any unique instructions, and 
to capture the staffing level decisions. 

The experimental sequence of events had the subjects 
performing a DUMMY simulation two days prior to the actual day 
of the experiment. As previously stated, the DUMMY simulation 
was designed to be as closely identical to the actual 
experiment as possible without revealing the nature of the 
experiment to be conducted. As such, the documentation 
provided to each subject closely followed the documentation 
that was used for the experiment. Appendix I is a copy of the 


DUMMY documentation set provided to each experimental subject. 
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The DUMMY documentation differs onlywin refereneeN c DN 
versus multi-project environments and most significantly in 
the area of compensation. The instructions for compensation 
specified in the DUMMY documentation identify that the 
performance criteria is strictly calculated as a function of 
Schedule and budget overruns. The experiment documentation 
uses the same base calculation for performance; however, the 
multi-project environment provides the opportunity to affect 
the manager's motivation to perform. 

When constructing both the computer interface and the 
written instructions, it is important to eliminate any 
external bias in the experiment environment. Unless the 
research question is directly dependent on the gaming 
interface itself (as is the case when evaluating feedback 
models), the computer interface should be identical for each 
subject. As a result, the documentation itself represents the 
primary means to convey unique information to a subject. The 
unique instructions for the experiment documentation appear on 
the second page of Appendix J. Each subject was told that 
his/her compensation was based on either 80% individual or 80% 
combined performance. Appendix J is the unique set of 
instructions provided to the "AI" group of subjects. This 
designates that this Player A was independently motivated. In 
the multi-project environment the method of motivation served 
as the independent variable for this experiment. The section 


titled "YOUR GRADE" identified to the subject the motivation 
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method in terms of the manner in which his performance would 
be compensated. Figure 2-5 is the unique instruction that all 


individually-motivated subjects received. 
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Ж 80% of your compensation will be based on your 
5 subsystem's performance. 

* 20% of your compensation will be based on total 
* project performance. 

* 
* 


+ + X X 0€ 0E ox 
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Figure 2-5 Compensation Criteria for Individual Motivation 


Figure 2-6 is the unique instruction that all team- 


motivated subjects received. 
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IMPORTANT 
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x 20% of your compensation will be based on your 
* subsystem's performance. 

х 80% of your compensation will be based on total 
* project performance. 

* 
* 
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Figure 2-6 Compensation Criteria for Team Motivation 


The 80-20 split was chosen as a realistic motivation 
environment that may be employed in actual software 
development management, where 100% in either direction may be 


unrealistic. 
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Both the DUMMY and the experiment documentation identify 
to the subject some important considerations. These 
considerations include information on how the size of the full 
time staff is dynamically affected by: work force ceiling, 
hiring delays, assimilation time, and turnover rate. The 
subjects were provided with clear instructions that they may 
not exceed any imposed work force ceiling. A simple heuristic 
for calculating a minimum staff level required at any 
reporting period was also provided both by instruction and by 
example. During the training session conducted on the day of 
the DUMMY simulation it was stressed that this heuristic did 
not take into account all the staff level dynamics identified 
above, rather that they would also need to use their 
judgement. 

The documentation also includes a step-by-step set of 
instructions on the exact keystroke sequence of events 
required while using the computer gaming interface. At the 
end of the training session and the DUMMY simulation, all 
experimental subjects were interacting with the gaming 
interface without error. 

The final page of the documentation handout is the 
staffing level record sheet. This page identifies to the 
subjects the initial estimates for the size, cost, duration 
and core team. The DUMMY documentation identified these 
values for the single project being managed. The experimental 


documentation identified these values for the subject’s 
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subsystem and his counterpart's subsystem. Tasks roughly 
represent 50 lines of code and the core team represents the 
group of software professionals that developed the subsystem's 
requirement specification. For Player A the initial size and 
duration of the subsystem was specified as 396 tasks and 1,111 
man days, respectively. For Player B the initial size and 
duration of the subsystem was specified as 475 tasks and 1,345 
man days, respectively. The size of the initial core team was 
set at five people. In order to provide consistency 
throughout the experiment, the terms "Your Subsystem" and 
"Other Subsystem" were used both in the documentation and in 
the gaming interface. As such, the final page of the Player 
B documentation reverses the order of appearance of the 
initial estimate information. The final page of the Player B 
documentation is provided as Appendix K. The Dynex gaming 
interface was constructed to impose a work force ceiling of 
fifteen for both subsystems combined, or the project as a 
whole. Taking into account that the Player A subsystem 
increased in size and the Player B subsystem increased in 
complexity during the life of the project, and through several 
trial simulations, a work force ceiling of 15 was determined 
to be just barely enough to complete the two subsystems within 
a reasonable budget and schedule. 

The Dynex software uses a file called "filename.WAS" to 
store temporarily the staffing level variables used by the 


Dynamo Simulation. With each iteration, this .WAS file is 
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overwritten and the information is lost. The record sheet is 
therefore the only practical means to capture the staffing 
level decisions. The only means to by-pass this limitation is 
to include the staffing variables WFNTR1(1) and WFNTR1(2) in 
the output report. This may or may not be desirable. 


Validation of this written data is discussed in Chapter IV. 


D THE TRIAL EXPERIMENT 

Once the gaming interface and the documentation have been 
prepared, trial experiment (s) should be conducted to provide 
the researcher with feedback on any potential design or 
implementation problems. Two students who had knowledge of 
the System Dynamics Model beyond that of the remaining sample 
population were selected to play the experiment simulation as 
a trial experiment or pilot study. The objective of the trial 
experiment was not to measure the performance, but rather the 
interaction of the students with the documentation and the 
gaming interface. The following is the initial list of 
objectives for conducting the trial experiment. 

— Are the instructions clear? 


— Do the subjects appear to be comfortable with the 
interface? 


— Ном long does the experiment take? 


- How do the subjects interact with each other during the 
experiment? 


The trial experiment was conducted using the documentation and 


interface for the multi-project experiment. At the time of 


26 


conducting the trial experiment a second research question was 
under development and considered for inclusion as a second 
experiment. This second research question would have had each 
subject manage a single project similar to the DUMMY 
experiment before completing the multi-project experiment. 
Due to the time limitations, the potential for biasing the 
subjects for the multi-project experiment and the following 
findings of the trial experiment, the single project 
experiment was dropped. The following is a long but not 
comprehensive list of pertinent observations and lessons 
learned as a result of conducting the trial experiment. 

- Elapsed time 1 hour 40 minutes. Keeping in mind that this 
experiment will be preceded by a DUMMY experiment and 
PROJECT1, an estimated time range for all subjects would 
probably be on the order of 2 to 3 hours. This could be 
a problem in terms of lab assets and attention span. 

— Though time is limited, running DUMMY and PROJECT1 on one 
day and PROJECT2 on another would ease the time pressure 
and ensure that the sample population is familiar with the 
interface prior to running the multi-project experiment. 


- Both subjects appeared to be seriously conscientious. 


— They read the instructions carefully without any 
questions. 


— They were careful not to divulge any information to their 
counterpart. 


— They complained initially about the simulation speed 
associated with disk reads from the A drive but did not 
persist once they accepted the conditions. The simulation 
seemed to run reliably from the A drive. 


— Player B was very familiar with the model and immediately 
tried to out-game the simulation. 


- Both subjects spent a good deal of time studying the 
oUgcrpub report. 
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Need to tell the sample population to bring calculators to 
the simulation. 


Player B questioned if 40 days equals 2 working months. 


Both subjects spent an extraordinary amount of time trying 
to solve the "optimal" COCOMO solution and appeared 
frustrated with their attempts. As much time was spent 
with a calculator and paper as with the entire rest of the 
experiment. This consumed a tremendous amount of time and 
could result in some subjects taking more time to complete 
all three project sets than the allotted time for the use 
of the labs. 


Player A noticed the increase in tasks after period 2 and 
expressed some distress. At the end of the simulation 
Player B noticed that tasks had not increased yet progress 
toward development dropped significantly following period 
4. Player B expressed that this was probably attributed 
to a decrease in personnel productivity and seemed very 
upset that this was not measurable. Player B’s project 
stalled even though tasks did not change and staffing was 
high. This subsystem was ultimately much higher in cost. 


Both subjects seemed to have become very familiar with the 
environment and would serve well as lab attendants. 


With Player A’s subsystem having escalating tasks and 
Player B’s subsystem having some dynamic change in 
productivity, performance comparison seems to only be 
valid in A to A and B to B vice A to B. 


Subject B calculated that the 50 lines of code per task 
times the initial estimate of the number of tasks produced 
a number of lines of code which when entered into the 
basic COCOMO formula did not match the initial staff size 
of 5 people. 


The only available explanation was that the LOC/Task is an 
approximation and that the COCOMO calculations are tenuous 
in a dynamically-simulated environment. 


On the first time at the MAIN MENU screen, both subjects 
hit ENTER after selecting option one and returned to the 
MAIN MENU. This was never repeated as a problem once the 
mechanics of the interface were understood. 


This researcher does propose that with one menu option it 
would seem to make sense that the MAIN MENU screen is not 
needed. This option has been investigated on a 
preliminary basis and is determined to be such an integral 
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component to the structure of the main batch file that an 
entirely new batch file structure would have to be 
adopted. This would probably take longer to change than 
the allotted time available. 


- Researcher’s note: If the variable which will serve as 
the basis for statistical analysis is the staffing levels 
chosen then it would seem important to capture this data 
electronically vice depending on the documentation sheets. 
Several times the subjects were reminded to record their 
decisions on the documentation sheets. The only known 
possibility for this is to include the WFNTRI1 for each 
period in the status report ("Your Selected Staff 
Size...") and capture the .OUT files. Since the inputs 
are overwritten in the .WAS file the above option is the 
known possibility. 


- After period 4, Player B hit key 2 to proceed to the next 
Simulation and could not return to view the status report. 
The experiment continued with Player B leaving the 
staffing level for period 5 the same. This does not 
appear to have been a problem with previous research and 
was not repeated as a mistake again. A loop at this point 
may be possible, but could take longer to program than the 
remaining time. 


- Both subjects began reducing staff size by period 6. If 
constrained resources is intended to be a research 
environmental condition, then a max ceiling of 20 is 
recommended with anything less (i.e., 15) increasing the 
pressure and influencing the outcome. 

A quick scan of the above observations indicates the 
breadth and depth of information gleaned from the trial 
experiment. This information proved invaluable in shaping the 
content, structure and format for conducting the experiment. 


The two students who participated in the trial experiment were 


later used as lab attendants for the actual experiment. 
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E. FINAL PREPARATIONS 

Having prepared the gaming interface and the documentation 
for the multi-project experiment, the lessons learned from the 
trial experiment produced a single research question: Whether 
team motivated multi-project managers performed better than 
individually motivated project managers. The work on the 
gaming interface with modifications adopted as a result of the 
trial experiment produced the clean base set of 13 files. 
There were two versions of the base set. The Player A and 
Player B versions of the software differed only in the Dynex 
control file. The first difference is that the input 
variables WFNTR1(1) for Player A and WFNTR1(2) for Player B 
reverse order of appearance such that the specified Player's 
variable appeared first аз "Your  Subsystem" апа the 
counterpart variable appeared second as "Other Subsystem." 
The second difference is in the report format at the end of 
the Dynex file where all report variables use the (1) or (2) 
subscripts depending on which Player's disk was specified. 
Remeinber also that the PROJECT.DRS file duplicates the report 
format and the associated subscripts. The identical Player A 
or Player B set of files was used regardless of motivation 
method specified in the documentation. 

The final smooth copies of the documentation required a 
unique set of instructions for each of the four groups: "AI," 
ЗАТ TBI; апач ваи Each of these sets of instructions 


differed only in the compensation message on page two for 


5/0 


individual or team, and the order of the initial estimates on 
the final page for Player A or Player B. The results of the 
preparation produced a clean set of instructions and a single 
floppy diskette for each unique subject group. 

Other preparations included: verifying the scheduled 
availability of the lab and sample population, preparing 
lecture notes for the training session, and hardware 


pretesting. 
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III.  CONDUCTING THE EXPERIMENT 


A. TASKS AND PROJECT CHARACTERISTICS 

By completing the introductory training session and DUMMY 
simulation two days prior to the day of the actual experiment, 
the research subjects were familiar with the Dynamo gaming 
interface and skills required to manage software projects. 

Project two was the experiment simulation scenario 
designed to address the research question. The simulation was 
designed to allow the experimental subjects, working together 
as management pairs, to make staffing level decisions for one 
of two subsystems every forty days until the completion of 
both projects. The subsystem manager acts as a resource 
manager who must allocate his/her manpower resources as 
necessary to complete the project on time (days) and on budget 
(nan days). Subjects used the gaming interface to enter the 
Staffing needs for the two subsystems and were provided with 
an Output report which provided the subjects with a status 
report of their progress at intervals of forty days. тше 
Status report was designed to be in a standard text format 
which allowed the data in each output report to be captured by 
the gaming interface. The final cost and schedule data were 
then obtained for each individual and also for each managing 


pair. 
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The staffing level decisions were entered into the gaming 
interface as well as recorded on the final page of the 
documentation sheet. Both subsystem staffing level decisions 
were recorded as a measure of comparison. 

Each student's participation grade in the Software 
Engineering course was contingent on participation in the 
simulation. This was used as an instrument to keep the 


subjects motivated. 


B. ORGANIZING THE EXPERIMENT 

The experimental setting consisted of a ten-minute 
classroom training session in which the nature, sequence of 
events and instructions were verbally explained to the 
subjects. The subjects moved from the classroom to one of two 
preassigned labs down the hall. Each lab had 12 80286 
personal computers. Each student had a folder sitting on the 
keyboard of a preassigned PC with his or her name on it. In 
order to avoid inadvertent sharing of status report 
information, subjects were instructed to turn their monitors 
so that they faced away from their counterparts. The 
experiment was conducted ina single day. 

The details which were required prior to the day of the 
experiment involved the preparation of the individual folders, 
setup and testing of the hardware, and assignment of seating. 
Within each folder were a set of instructions and a floppy 


diskette. There were four unique sets of instructions 
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corresponding to the group to which each subject was assigned. 
The instructions revealed for the first time to the 
experimental subjects the nature of the compensation method 
which would be used to evaluate their performance. In 
essence, the subjects were uniquely motivated by the method 
(individual or team) as specified in the documentation 
provided to each subject. The computer disks in each folder 
were prepared with the simulation files needed to run the 
experiment and included a volume label with the name of the 
Subject. The volume label served as a redundant check with 
the initial information captured by the gaming interface, 
which identified the data as coming from a specific subject. 

A lab attendant was available in each lab to answer 
general questions about the procedure or gaming interface. 
The lab attendants did not answer any substantive questions 
with respect to the staffing level decision to be made. Asa 
measure of safety and redundancy a full set of backup 
diskettes and instructions were available so that any problems 
could be immediately resolved. 

The current version of the Dynamo software is only 
compatible with MS or PC DOS versions up to 3.3. Some of the 
lab machines were using DOS 4.01 and were not usable for the 
experiment. Later testing of the software using MS DOS 
version 5.0 revealed that Dynamo was not compatible with it 
either, even when using the SETVER.EXE function to report an 


earlier version of DOS to the software. 
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C. THE SAMPLE POPULATION 

The subjects for this experiment consisted of students 
from two segments of an IS-4300, Software Engineering and 
Management, course at the Naval Postgraduate School. Segment 
one consisted of 26 students and segment two consisted of 28 
students. In order to randomize the sample population, assign 
them to pairs, and designate them as either individually or 
team motivated, the following matched sample procedure was 
used [Ref. 8:p. 263]. 

An alphabetical list for each segment was used along with 
a standard table of random digits to perform a Lwo-level 
randomization [Ref. 8:p. 598]. Appendix L includes the sample 
population randomizing worksheet used for each segment. 
Column A is the alphabetical listing of the students in each 
segment. Column B is a two-digit random number taken from the 
standard table of random numbers and assigned to each student. 
For segment one, column B consists of two-digit numbers 
assigned beginning with row one of the table. Likewise for 
segment two numbers were assigned beginning with row 2. For 
each segment the list was then sorted into ascending order of 
random number. This randomized the alphabetical listing in 
the first level. At this point the pairs were determined with 
the first two students forming a pair, etc. The second level 
was to randomly determine which of the students in each pair 
would be assigned as Player A and which would be assigned as 


Player B. Using the random table, the first member of the 
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pair was assigned a random digit and is shown in Column E. 
Row 5 was used for segment 1 and row 6 was used for segment 2. 
An occurrence of an odd digit assigned the first student in 
the pair as Player A and the occurrence of an even digit 
assigned the first student as Player B as shown in Column F. 
With this two-level randomization completed, there were 13 
pairs in segment 1 and 14 pairs in segment 2. The pairs were 
split in half for each segment in order to provide roughly an 
equal number of individual and team motivated pairs as shown 
in Column G. Simply assigning one segment as individual and 
one segment as team was avoided since conclusions could 
possibly be attributed to segment or time of day dependency. 

The training session and DUMMY simulation were conducted 
two days prior to the day of the experiment. Five students 
did not receive this training and were dropped from the sample 
population. These students are designated in Appendix L by 
the shading of their name. In order to maximize the number in 
the sample population, the counterparts of those who were 
dropped from the list were reassigned. In segment one, Fortin 
waS reassigned from a "BI" to a "BT" and paired with McKeon. 
Hedges was dropped completely. In segment two, Wawrzeniak was 
reassigned from a "BT" to a "AT" and paired with Montgomery. 
A total of six students were dropped from the list, and the 
revised assignment of pairs and designation as either 


individual or team is shown in Appendix M. This left mk 
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subjects in each of the four groups or a sample size of 12 
pairs for a team versus individual comparison. 

Each sample pair was assigned two specific computers in 
the lab. Appendix N is the seating chart used to ensure 
alternation of Player A and Player B subjects in the lab. 
This prevented Player A and B monitors from directly facing 
each other. Subjects also were instructed to perform their 
own work and that, with several versions of the simulation 


being used, anyone else's data could be misleading. 


D. DEPENDENT MEASURES 

The first dependent variable measured as an output of the 
simulation was final cost. The line on the status output 
report screen from Appendix C which reads, "Total Man Days 
Expended to date" is the cost at the end of any reporting 
period. Upon completion of the simulation, this variable 
represents the final cost. Completion of the simulation is 
signified when "$ Development (Design & Coding) Reported 
Complete" and "$ Testing Reported Complete" are both 100 
percent. This data is available for each individual. Subject 
pairs were instructed to add this number for both subsystems 
to report the final cost for the project as a whole. This 
data was later validated. 

The second dependent variable measured as an output of the 
simulation was the final schedule. The line on the status 


report which reads, "Updated Est. of Subsystem Duration 
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(start-end)" is the projected subsystem completion date at the 
end of each reporting period. This variable is determined by 


the Dynamo simulation based on the status of the subsystem at 


that specific moment in time. It projects the actual 
completion date. Upon completion of the simulation this 
variable specifies the final schedule. This variable also 


closely projects the final schedule if the development and 
testing do not reach 100 percent. The subject pairs were 
instructed to record the larger of the two subsystem values 
for schedule as the final schedule for the project as a whole. 

The final measure collected as a point of comparison was 
the actual staffing level decisions for each player. Each 
subject coordinated and negotiated his staffing level needs 
and recorded the entries for both subsystems оп the 
documentation sheet before entering them into the computer. 
Figure 3-1 identifies the independent variable and the 


dependent variables. 
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Final Schedule 


Staffing Decisions 





Figure 3-1 Independent and Dependent Variables 


As discussed earlier, the documentation sheet was the only 


means to capture this data. In the design of the 
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documentation sheet, the column for recording the "OTHER 
SUBSYSTEM" staffing levels provided a cross check for 
accuracy. The data in this experiment contained six staffing 
level sequences which did not match within team members. This 
is resolved later. In addition, the Dynamo gaming interface 
does not allow some projects to reach design and testing 
completion of 100 percent. Under certain combinations of 
staffing level entries the simulation will signify completion 
by repeating status report information with the value 
specified at around 97 percent design and testing completion. 
The general heuristic used to verify that a simulation was 
indeed complete was to accept the data on the second 
occurrence of the 97 percent report. 

In order to resolve any doubt that any simulation had 
reached completion or that the exact staffing level decisions 
were determined for each subject, a series of verification 
runs were used to duplicate a team's experiment. Since the 
Dynamo model responds identically under identical 
circumstances, this measure firmly confirmed the data accuracy 
for these subjects. Without exception all 48 students' data 
were accepted as correctly recorded and their data validated. 
Appendix P shows two of the staffing level decision data 
validation runs. For example, the Bryant data is the data 
from the subject's INFO1 file from the actual experiment, 


while the X-Bryant data is the data from the INFO1 file from 
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the validation run. Notice the identical results, which 


verifies that the data recorded was accurate. 
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ТУ. EXPERIMENTAL RESULTS AND ANALYSIS 


A. MODEL OF ANALYSIS 

The raw data produced by the multi-project experiment 
produced a final cost and schedule for each subsystem manager. 
The final cost and schedule were combined for each managing 
pair in order to obtain the final cost and schedule for the 
project as a whole. Since the subsystems managed by Players 
A and B were very much different in their design, there are 
three areas of comparison in analyzing the data. The first is 
the individual versus team performance for the project as a 
whole. The second is the individual versus team performance 
for the Player A subsystem. Thesthird IS the individual 
versus team performance for the Player B subsystem. 

Cost and schedule are dependent variables which are 
evaluated using the SAS General Linear Models procedures. 
Specifically, the Multivariate Analysis of Variances (MANOVA) 
procedure is used to provide the test criteria and exact F 
statistic for the null hypothesis of no overall GROUP effect 
on the performance measures. This is done for each of the 
three areas of comparison with GROUP defined for each. Beyond 
the multivariate analysis, each is further evaluated on the 
basis of the univariate analysis for each of the dependent 


variables. For each area, these data will answer whether the 
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means compared differ significantly, but not indicate which of 
the means has deviated. To clarify the questions raised by 
the analysis of variance procedure, the means and standard 
deviation statistics are provided. [Ref. 5] [Ref. 6] [Ref. 7] 

The raw data is presented in Appendix Q in the form of SAS 
data files. The raw data includes the name of the subject and 
his final cost and schedule. Each subject was assigned a 
numerical value as an administrative tool for ordering the 
subjects into groups. The actual variables used for data 
analysis are the percent deviation of cost and schedule from 
their initial values. The SAS control files are included in 
Appendix R and calculate two new variables: DIFFCOST апа 
DIFFSKED. As an example DIFFCOST is calculated as final cost 
minus initial cost divided by the initial cost. For each area 
of comparison a final analysis of variance procedure is 
conducted on the average cost plus schedule deviation. This 


is a new variable called COSTSKED. 


B. RESULTS 
These results are presented primarily on the basis of the 
analysis of the dependent variables and the impact that each 
incurred as a result of the individual or team GROUP 
identified in each of the three areas identified below. 
1. Student Grade Distribution 
In order to validate the randomization of the sample 


population, a two-level SAS analysis was performed to 
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determine if there was any significant difference in the 
academic performance of the experimental population. The 
sample population was randomly divided into pairs resulting in 
each subject being designated as either Player A or Player B 
and designated as either Individual or Team. The SAS data 
files in Appendix Q includes a listing of the subjects with 
their two-level designations and assigned grades in the 
Software Engineering course completed while experimental 
subjects. The SAS control file (GRADES.SAS) in Appendix R 
identifies the statistical comparison of the sample 
population. Groupl corresponds to the Individual or Team 
designation and Group2 corresponds to the Player A or Player 
B designation. The analysis of variances procedure for each 
of the two levels of comparison identifies by the F statistic 
that there is no statistical significance in the distribution 
difference of the sample population. Thus, we reject the 
alternate explanation that any difference between experimental 
conditions was caused by difference in population 
characteristics. 
2. Outliers 

Preliminary SAS data analysis was performed on the raw 
data and revealed no significant findings, which led to an 
evaluation of the raw data for noise which would need to be 
eliminated. The Linear Structural Relations (LISREL) 


procedure was applied to the raw data to test for multivariate 
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normality [Ref. 9]. This procedure identified four subjects 
which were outliers in the data set and Nad to Бе ао ш 
The four subjects were: Carney, Frierson, Stone, and Ditri. 
In addition to these four, their managing counterpart also had 
to be dropped. They were: Laskowski, O'Connor, Coley, and 
Clark. These eight subjects represented two individuals in 
each of the four groups: AI, AT, BI, and BT. The remainder 
is a sample size of 10 for each group. 
3. Staffing Level Decisions 

The staffing level decisions for each of the valid 40 
subjects is presented in Appendix O. For each of the four 
groups the mean (of 10 subjects) staffing level decisions for 


each time period was determined and plotted in Figure 4-1. 
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Figure 4-1 Staffing Level Decisions 
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The noticeable observations in Figure 4-1 are that as a 
group, the "Team"-motivated subjects were quicker to utilize 
more of the available resources. This held true regardless of 
managing either the Player A or Player B subsystems. їп 
addition, the "Individually"-motivated subjects reacted late 
and increased their staffing level requirements noticeably 
towards the end of the project. This too is independent of 
the Player A or Player B subsystem managed. In general, the 
team-motivated curves are more consistent with less of the 
dramatic changes characteristic in the individually-motivated 
curves. 

4. Individual versus Team, Combined Analysis 

This area of comparison combines the final cost and 
Schedule for the project as a whole. The subject's data are 
combined to provide 10 individual pairs (AI, BI) and 10 team 
pairs (AT, BT) for comparison. Group is defined in this case 
as either "Individual" or "Team." The null hypothesis is that 
the group has no affect on final cost and schedule. Table 4-1 
provides the means and standard deviation for cost апа 
schedule in each group. The data in the table reveals that 
the team group has a lower mean value, which indicates that as 
a group they were closer to the initial estimates. Also, in 
both groups the deviation from schedule was much less than the 
deviation from the budget. This may be partially attributed 


to the fact that the resource constraints were liberal enough 
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to allow a subject to pursue schedule as a higher priority 


regardless of cost. 


TABLE 4-1 PROJECT MEANS AND STANDARD DEVIATION 


| Combined | Variable | MEAN | STD DEV 
0.3144 0.1052 


0.7894 0.0091 


DIFFSKED 0.2441 0.0438 





In table 4-2 the F statistic Pr > Е indicated by the 
MANOVA analysis shows that the difference between the 


individual and team groups is significant at p < 0.07. 


TABLE 4-2 PROJECT MULTIVARIATE ANALYSIS 


зы == — 


DIFFSKED 0.0668 
aoa | ------ — | 3.154 | 0.0408 


Cos к ъкеа (5/359 EU 0.0368 





Thus, the null hypothesis is rejected. When testing the null 
hypothesis for the combined cost and schedule, the F statistic 
clearly rejects the null hypothesis. This is a clear 
Statement that the slightly better performance of the team- 
motivated group as indicated in Table 4-1 is statistically 


significant in measure. 
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5. Individual versus Team, Player A Analysis 

This area of comparison groups the 10 Player A 
"Individually"-motivated subjects (AI) with the ten Player A 
"Team"-motivated subjects (AT) for comparison. The hypothesis 
here is that within a subsystem which roughly doubles in size 
during the lifecycle, that individual versus team-motivation 
groups do not significantly affect the dependent performance 
measures of final cost and schedule for that subsystem. Table 
4-3 provides the means and standard deviations. While those 
Player A subjects who were team motivated had a lower 
deviation from schedule (0.0297), the recurring theme is that 
regardless of the motivation method, budget was sacrificed in 


favor of schedule. 


TABLE 4-3 PLAYER A MEANS AND STANDARD DEVIATION 


| Player A | Variable | MEAN | STDDEV | 
E UP. ДЫ» 
0.1156 0.1845 


0.5700 0.0221 
0.0297 





Table 4-4 (Pr > F) indicates that the null hypothesis сап 
not be rejected. This signifies that in a subsystem which 
increases dramatically in size, method of motivation is not a 


factor. 
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TABLE 4-4 PLAYER A MULTIVARIATE ANALYSIS 


|  prrrcosT 
|  DIFFSKED 
— 0.4048 


Cost 4 Sked Дм 2 61-222) 











6. Individual versus Team, Player B Analysis 


The final area of comparison groups the 10 Player B 
"Individually"-motivated subjects (BI) with the 10 Player B 
"Team"-motivated subjects (BT) for comparison. The hypothesis 
here is that in subsystems which roughly double in complexity 
during the lifecycle, that the team versus individually- 
motivated groups do not significantly affect the dependent 
performance measures of final cost and schedule. Table 4-5 
provides the means and standard deviations. The relationships 


identified with Player A also holds true with Player B. 


TABLE 4-5 PLAYER B MEANS AND STANDARD DEVIATION 


| layer B | variable | MEAN — | STD DEV 
Individual DIRERCOST 0.9972 0.0506 
0.3031 0.0850 


0.9707 0.0184 
0.2441 0.0436 





While there is slightly better performance for the team- 


motivated Player B subjects in terms of final schedule, it is 
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the recurring theme of sacrificing budget for schedule which 
reappears. The interesting finding is in the univariate 
analysis of variance for schedule identified in Table 4-6. 
While the MANOVA test does not reveal a statistically 
Significant difference between the individual and team groups, 
there is a difference between the two groups with respect to 
the final schedule (р < 0.07). This indicates that in 
subsystems which increase in complexity during the lifecycle 
that managers who are team motivated perform better when 
trying to meet a prescribed schedule. This is even further 
supported by the results of the combined cost and schedule 


analysis of variances. The F statistic in this case (0.0319) 


TABLE 4-6 PLAYER B MULTIVARIATE ANALYSIS 


DIFFCOST 
DIFFSKED 


Cost + Sked 





soundly rejects the null hypothesis that group does not affect 
overall performance. In fact it is clear that in projects 
which increase in complexity, management method does make a 


difference. 
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7. Repeated Measures Analysis 

A repeated measures analysis was conducted for 
evaluating staffing level decisions. The staffing level 
decision data for the "AI" versus "AT" and the "BI" versus 
"BT" comparisons are included in Appendix Q. The related SAS 
control files are included in Appendix R. A graph of the 
Staffing level decisions is included earlier in this chapter. 
The following results of the SAS analysis report the findings 
identified in the Wilks' Lambda statistics. 

The first test evaluated the hypothesis of no TIME 
effect on the staffing level decisions. The "BI" versus "BT" 
comparison is significant {F(7,12) = 4.74, p < 0.01} while the 
"AI" versus "AT" comparison is not significant {F(7,12) = 
1.41, р < 0.29}. Thus, there is a time effect for staffing 
level decisions for projects which significantly increase in 
complexity, but not in size, over the life of the project. 

The second test evaluated the hypothesis for between 
subjects effects. The "BI" versus "BT" comparison is 
significant {mean: 13.2; F value: 9.04; p < 0.01} while the 
"AI" versus "AT" comparison is not significant {mean: 9.6; F 
value: 1.75; p < .20}. It appears that the staffing level 
decisions for project "B" were affected by the specific group 
assigned while the staffing level decisions for project "A" 


were independent of group assigned. 
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The third test evaluated the hypothesis of по 
TIME*GROUP effect. None of the comparisons were significant, 
which indicated that group behavior did not differ over time. 

The results of the repeated measures tests show that 
the behavior of the subjects who managed subsystems in which 
complexity roughly doubled over the life of the project 
differs depending on their method of motivation. Combined 
with the findings above, these results suggest that subsystem 
managers who are managing projects which significantly 
increase in complexity during the lifecycle behave differently 


when team motivated, and perform better. 


C. SUMMARY 

The multi-project experiment was conducted using a 
properly randomized sample population. This was verified by 
statistical analysis of.the grade distribution of the assigned 
subject groups. Subject data which fell outside the range of 
normality were eliminated as noise which could contaminate 
statistical analysis. Figure 4-7 summarizes the specific 
findings of the thesis. The following items summarize these 
three findings: 

° The performance of subsystem managers in a multi-project 
software development environment is significantly better 
when the managers are provided with a "Team" incentive 
structure versus an "Individually"-competitive structure. 

e The performance of subsystem managers in a subsystem which 
roughly doubles in complexity during the project lifecycle 


is significantly better when provided with a "Team"- 
incentive structure. These managers performed 
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significantly better when trying to meet a prescribed 
schedule. 


e The performance of subsystem managers in a subsystem which 
roughly doubles in size during the project lifecycle is 
not significantly different for either incentive 
Structure: 










PERFORMANCE ENVIRONMENT 


Ted Multi-project systems, 
overall. 


т> т Subsystems which double 
in complexity. 


i 
| 
i 
L- — ee ——————— s 


Т= І | Subsystems which "me 
in size. 
Figure 4—7 Multi-Froject Experiment ounmnani 
The measure of performance in each case is the ability of 
managers to meet final cost and schedule in a dynamic software 
development environment. In all cases, the deviation from 
final schedule was less than the deviation from final cost. 
Further, the staffing level decisions reveal that the work 
force ceiling imposed allowed completion of the experiment 
with excess staff resources. The finding associated with 
these facts indicates that if the staff resources are 
available, that managers will sacrifice final cost in order to 
meet the final schedule. 
The trends implied by the staffing level decisions 
indicate that "Team"-motivated managers use the available 


resources more efficiently. The "Individually"-motivated 
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managers tended to use fewer resources early and to increase 


rapidly the staff size at the end of the project. 
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V. CONCLUSIONS 


A. FINDINGS AND IMPLICATIONS 

The objective of the thesis has been two-fold: to conduct 
an experiment on multi-project management motivation and to 
produce a template thesis which serves as a basis for future 
experimental studies. 

In a time of decreasing budgets and increasing oversight, 
the thesis creates and tests by experimentation the affects of 
"Team" versus "Individual" motivation on managers who are 
operating with limited staff resources. To date, software 
project cost estimation tools have proven effective for 
predicting a project's cost and schedule in a set environment. 
These cost estimation tools are company specific and must be 
evaluated over time. As recent Congressional reports have 
indicated, industry in general and the Department of Defense 
specifically continues to have disastrous problems with cost 
and Schedule overruns. These overruns are costing millions of 
dollars and damage the confidence and credibility of software 
cost estimation. 

The problem stems from the fact that there are sufficient 
software development and estimation products available, yet a 
correct management process has not been identified. This is 


primarily due to the extreme dynamics that surround software 
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development. It is therefore necessary to model this 
environment and test management theory. 

The thesis was designed to investigate the affects of 
incentive structure on management performance, by using the 
System Dynamics Model gaming interface. Managers were 
provided with either a competitive or cooperative incentive 
structure for two project subsystems with limited staff 
resources. The experimental results confirm that project 
management teams perform better when trying to deliver a 
software project on time and on budget, while operating under 
restricted resources, and when provided with a cooperative 
incentive structure. These findings suggest that in dynamic 
environments with limited resources, team-motivated management 
pairs are more successful in delivering software projects on 


time and on budget. 


B. FURTHER RESEARCH 

There are four significant areas of potential research 
using the SDM gaming interface to investigate managerial 
heuristics in software development. 

The first area involves a replication of this multi- 
project experiment and delaying the start of the second 
project. Preliminary simulations conducted during the design 
formulation for this thesis follow the indications specified 
in previous research that such a dynamic environment might 


affect the quality of management decisions. The simulations 
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conducted during design indicated that final effort and "cost 
reacted most strongly with a 100 day delay in the start of the 
second subset. 

The second area involves combining this multi-project 
experiment with a single project environment to reveal if the 
pressures associated with managing more than one project at a 
time has an affect on the quality of project management. 

The third area involves a replication of this multi- 
project experiment with significant increased stress on the 
managers by causing high personnel turnover. This further 
examines the crisis-management tendencies of managers. 

The final area involves an experiment using a new gaming 
interface under development which would allow the manager to 
manipulate several management decisions in addition to the 


staffing levels. 
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APPENDIX A:  DYNEX PROGRAM FILE (EXP1.DNX) 


if #tm<.1 then 
display clear 


Important Points to Remember !!!!!!!!! 
X k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k X K 


You are not allowed to discuss this exercise with anyone 

other than a lab attendant. Please refrain from discussing 

this with other class members until they have completed 

the exercise. 

The system w1ll start by showing you the size of the initial core 
team (they developed the requirement specifications). It will 

then ask you for your desired staffing level for the remainder of 
the project. 

Next it will run through the first simulation time period (2 months) 
and provide you with a status report. At the end of each reporting 
period, you will have an option to revise your desired staff level. 
Make your change to the desired staffing level both on the screen 
as well as on the documentation sheet provided. 

Keep in mind that if a work force ceiling is imposed on your 
project, the simulation will not allow you to acquire a staff 

level above that ceiling. 


A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 


GOOD LUCK! Press «ENTER» to continue. 


dendq 

choice 1 

cend 1/1 
display clear 


THE WORK FORCE CEILING FOR THIS PROJECT HAS BEEN SET AT: 7.5 


Tibetan wore Lit INITIAL CORE TEAM IS 5.0 People 


1) Enter your desired staffing level and press <ENTER>. 


Kk k Kk k k Kk k Kk x OR Kk kk Kk Kk xx xx 


2) Press <ENTER> to keep that same 5.0. 


The current staffing level = 


dendq 
dq WFNTR1(1)= 0<7.5 
display clear 
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Make sure that you have written your staffing 
level decision down on the Project 1 documentation 
sheet before continuing with the simulation. 


This is your final chance to change your 
Staffing level for this time period. Press 
ENTER to keep the same number or enter a 
new staffing level and press ENTER. 


The current staffing level - 
dendq 
dq WFNTR1(1)2 0<7.5 


else 


choice 1 
cend 1/1 


display clear 


INPUT YOUR DESIRED STAFFING LEVEL 


жхжххжжхххххххкхххкххкхкхххххххххххххх 


1) Press «ENTER» to maintain your last desired staffing level. 


*Ckokckck kc k kk QR ***k kk xkxk*k* 


2) Enter the new desired staffing level and press «ENTER». 


Your last desired staffing level was - 
dendq 
dq WFNTR1(1)= 0<7.5 
display clear 


Make sure that you have written your staffing 
level decision down on the Project 1 documentation 
sheet before continuing with the simulation. 


This is your final chance to change your 
Staffing level for this time period. Press 
ENTER to keep the same number or enter a 
new staffing level and press ENTER. 
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The current staffing level - 
dendq 
dq WFNTR1(1)= 0<7.5 


if #tm<90 then 
end 

end 

display clear 


Press <ENTER> to simulate the next time interval. 


dendg 

choice 1 

REPORT 

time-maxtime, 

FORMAT="40-" 

“PROJECT STATUS REPORT"; ; 
Bormat—"20<, 54<, 66<", PICTURE="Z, РОУ" 

ELAPSED TIME = = = = = = = = =>",tm, "Days"; ; 

Format="5<" 

"ESTIMATES MADE AT THE START OF THE PROJECT"; 
FORMAT-"8«,52«,66«",PICTURE-"2Z22,222V" 

NbLcJect Size",IPRJSZ(1),"Tasks"; 
FORMAT-"8«,52«,66«",PICTURE-"Z22, 222V" 

"Project Cost in Man Days", ITOTMD(1),"Man Days"; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,ZZZV" 

Beto ject Duration", TDEV(1),"Days";; 
Heemat="5<, 52<, 66<", PICTURE="222, Z229V" 

"PROJECT STATUS at Time = = = = = = = = = = = =>",tm, "Days"; 
FORMAT="8<,52<,66<" ,PICTURE="ZZZ,ZZ9V.99" 

"Updated Estimate of Total Project Size",PJBSZ(1), "Tasks"; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,Z2Z9V.99" 

"5$ Development (Design & Code) Reported Complete",PDVRC(1),"Percent"; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,229V.99" 

"$ Testing Reported Complete",PTKTST(1)*100,"Percent";; 
FORMAT="8<, 52<, 66<", PICTURE="222Z, Z2Z9V. 99" 

"Updated Estimate of Total Man Days", JBSZMD(1),"Man Days"; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,ZZZV.99" 

Nu ral Man Days Expended to date",CUMMD (1), "Man Days"; ; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,229V" 

aum dated Est. of Project Duration (start-end)",SCHCDT(1),"Days";; 
FORMAT-"8«,52«,66«",PICTURE-"ZZZ,ZZ9V.9" 

"Current Staff Size",FTEQWF (1),"Fulltime Staff";; 
FORMAT="5<" 

"PRESS <ENTER> TO RETURN TO MENU" 

cend 1/1 

spec md_length=#length+40 
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APPENDIX B:  DYNEX PROGRAM FILE (EXP2.DNX) 


if #tm<.1 then 
display clear 


Important Points to Remember !!!!!]!1!1! 
Kk K K K K k k K k K K K K K K K k K K K K K K K K K K KX K K K K £ K X X X X 


- The system will start by showing you the size of the initial core 
team (they developed the requirement specifications). It will 
then ask you for your desired staffing level for the remainder of 
the lifecycle. 

- Staffing decisions need to be coordinated with the other subsystem 
manager to ensure that the sum of the two does not exceed the 
total project work force ceiling. 

- Next, the simulation will run through the first time period (40 days) 
and provide you with a status report for your subsystem. At the end 
of each reporting period, you will have an option to revise your 
desired staff level. Make your changes to the desired staffing level 
on the documentation sheet provided as well as on the screen. 

- Keep in mind that if a work force ceiling is imposed on your 
project, the simulation will not allow the sum of the staff requests 
for the 2 subsystems to be above that ceiling. 


A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 
- GOOD LUCK! Press <ENTER> to continue. 


dendq 

choice 1 

cend 1/1 
display clear 


THE WORK FORCE CEILING SUM FOR BOTH SUBSYSTEMS HAS BEEN SET AT: 15.0 
THE SIZE OF YOUR INITIAL CORE TEAM 425. 5.0 People 


FIRST, Determine your desired staff level alone. 

SECOND, Be prepared to present and defend your subsystem needs to 
the other manager. 

THIRD, When the other manager is ready, have a conference to discuss 
your needs. 

FOURTH, You must together: 


l. Agree on the desired staff levels for both subsystems. 
2. Ensure that the sum of both is below the work force ceiling. 


FIFTH, Enter the desired staffing level for both subsystems into the 
documentation sheet. (You both do this individually) 

SIXTH; Enter the desired staffing level for both subsystems into the 
Computer. Press «ENTER» to keep the current values, otherwise 


type in the new values. 
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Your subsystem current staffing level 


dendq 
dq WFNTR1(1)= 0<15 
display 
Other subsystem current staffing level = 
dendq 


dq WFNTR1(2)-2 0<$# (15-МЕМТВ1 (1)) 
display clear 


Make sure that you have written the staffing 
level decisions for both subsystems down on 
your documentation sheet before continuing 
with the simulation. 


This is your final chance to check and correct 
Staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected staffing levels and press ENTER. 


Your subsystem selected staffing level 


dendq 

dq WFNTR1(1)-2 0<15 

display 

Other subsystem selected staffing level - 
dendq 


dq WFNTR1(2)-2 0<# (15-ИЕМТВ1 (1)) 


else 


choice 1 
cend 1/1 
display clear 


INPUT YOUR DESIRED STAFFING LEVEL 
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 


SIXTH, Enter the desired staffing level for both subsystems into the 


Computer. Press <ENTER> to keep the current values, 


type in the new values. 


Your subsystem current staffing level 


dendq 
dq WFNTR1(1)-2 0<15 
display 
Other subsystem current staffing level - 
dendq 


dq WFNTR1(2)= O<#(15-WFNTRI1 (1) ) 
display clear 
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otherwise 


Make sure that you have written the staffing 
level decisions for both subsystems down on 
your documentation sheet before continuing 
with the simulation 


This is your final chance to check and correct 
staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected levels and press ENTER. 


Your subsystem selected staffing level 


dendq 

dq WFNTR1(1)-2 0<15 

display 

Other subsystem selected staffing level - 
dendq 


dq WFNTR1(2)= O<#(15-WFNTR1 (1) ) 


if #tm<90 then 
end 
end 
display clear 


Press <ENTER> to simulate the next time interval. 


dendq 
choice 1 
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REPORT 

time-maxtime, 

FORMAT-"40-" 

"SUBSYSTEM STATUS REPORT";; 
Formatz"20«,54«,66«",PICTUREz"2,229V" 

"ELAPSED TIME = = = = = = = = —»",tm,"Days";; 

Format="5<" 

"ESTIMATES MADE AT THE START OF THE PROJECT"; 
FORMAT-"8«,52«,66«",PICTURE-"222,222V" 

"Subsystem Size",IPRJSZ(1),"Tasks"; 
FORMAT-"8«,52«,66«",PICTURE-"222,222V" 

"Subsystem Cost in Man Days",ITOTMD (1),"Man Days"; 
FORMAT-"8«,52«,66«",PICTURE-"222,222V" 

"Subsystem Duration",TDEV (1),"Days";; 
Format-"5«,52«,66«",PICTURE-"222,229V" 

"SUBSYSTEM STATUS at Time = = = = = = = = = = = =>",tm, "Days"; 
FORMAT-"8«,52«,66«",PICTURE-"222,229V.99" 

"Updated Estimate of Total Subsystem Size",PJBS2(1),"Tasks"; 
FORMAT-"8«,52«,66«",PICTURE-"222,229V.99" 

"€ Development (Design & Code) Reported Complete",PDVRC(1),"Percent"; 
FORMAT-"8«,52«,66«",PICTURE-"222,229V.99" 

"X Testing Reported Complete",PTKTST (1)*100," "Percent";; 
FORMAT-2"8«,52«,66«",PICTURE-"222,229v.99" 

"Updated Estimate of Subsystem Man Days",JBSZMD(1),"Man Days"; 
FORMAT-"8«,52«,66«",PICTURE-"Z222,222V.99" 

"Total Man Days Expended to date",CUMMD (1),"Man Days";; 
FORMAT-"8«,52«,66«",PICTURE-"222,229V" 

"Updated Est. of Subsystem Duration (start-end)",SCHCDT(1),"Dpays";; 
FORMAT-"8«,52«,66«",PICTURE-"222,229V.9" 

"Current Staff Size",FTEQWF(1),"Fulltime Staff";; 

FORMAT-"5«" 

"PRESS «ENTER» TO RETURN TO MENU" 

cend 1/1 

spec md length=#length+40 


63 


APPENDIX C: 


SUBSYSTEM STATUS REPORT 


SAMPLE OUTPUT REPORT SCREEN 


ELAPSED TIME = = = = = = = = => 400 Рауз 
ESTIMATES MADE АТ THE START OF THE PROJECT 
Subsystem Size 396 Tasks 
Subsystem Cost in Man Days T DP Man Days 
Subsystem Duration 320 Days 
SUBSYSTEM STATUS at Time = = = = = = = = = = = => 400 Days 
Updated Estimate of Total Subsystem Size 610702 Tasks 
% Development (Design & Code) Reported Complete 100.00 Percent 
% Testing Reported Complete 100200 Percent 
Updated Estimate of Subsystem Man Days 1,714793 Man Days 
Total Man Days Expended to date 1,714.76 Man Days 
Updated Est. of Subsystem Duration (start-end) 290 Days 
Current Staff Size (WE Fulltime Staff 


PRESS «ENTER» TO RETURN TO MENU 
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APPENDIX D: BATCH CONTROL FILE (DUMMY.BAT) 


echo off 

CLS 

init 1 

GRAPHICS 

bat /N /p /s 

smlt EXP1 -go = -prs = -ls -ns -plm 6 -bw 


-top dynex EXP1 -in EXP1.STT -sc -ls -plm 6 -bw 
smlt EXP1 -gm = -ns -plm 6 -bw 
rep EXP1 -outf INTERVAL.OUT -t -bw >NUL 
rep EXP1 -bw >NUL 


infoofb 1 
Call -topl 
Exit 


goto -top$A 


-topl ФА = 1 
color \1F 


ram 
cls 


begtype 











ENSURE YOU HAVE VIEWED THE PROJECT STATUS REPORT 
\ IF FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION #2 
\Ip 1 \1Е VIEW PROJECT STATUS REPORT 

\1р 2 \1F PROCEED TO SIMULATE NEXT TIME PERIOD 


Choose an option: (DO NOT HIT <ENTER> AFTER SELECTION! !!!) 2 
end 


-lstkeyl inkey $0 | if %0 $ = 1 type $0; 
1Е %0 = keyOlb return 
goto -%0~1 


-2ndkeyl inkey $1 | if %1 # = 1 type $1; 


if $1 - keyOlb return 

if $1 - key020 goto -$$0$1 
if &1 = Кеу00а goto -$%0$1 
if %1 = key008 goto -topl 
if $1 - keyl4b goto -topl 


goto -%0%11 


-1-1 **** VIEW PROJECT STATUS REPORT ****x xxx x x x x x x o k k k 
rep EXP1 EXP1 -outf DUMMY.OUT -t -sc -ls -plm 6 -bw 
INKEY $0 
bat /p /s goto -topl 


-2-1  **** PROCEED WITH NEXT SIMULATION **** 4xXsXxXyxkkxxkkkk 
BAT CLS 
BAT COLOR \1F 
BAT BEGTYPE 
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K K k k k * k k £ k k * * k k k £ £ £ eoe oe oce oe oe oe eoe oe oe eoe eoo fece oe ee eoo eoe coe oe oec oo oe oe oe X í£ n x xA x 


* * 
* * 
* l. DETERMINE THE STAFFING LEVEL YOU DESIRE FOR THE ш 
* REST OF THE PROJECT. * 
* 2. WRITE YOUR DESIRED STAFFING LEVEL ON THE * 
* DOCUMENTATION SHEET PROVIDED. * 
* 35 PRESS «ENTER» * 
- ж 
ж ж 
ж zs 


ХЖЖжХАХХХЖХХХХХХХ ХЖҰХЖХЖАХЖАХХХЖ«ЖХХЖ««ЖХХХХХХХХХЖХХХХХЖХХХХАХЖХХАХЖХХХХХ ХХХ 


END 
bat /p /s goto -top 


-%0-1 
-5%061 
-%0%11 Беер goto -topl 


-On.error- 


if *R > 82 if *R < 90 type !! Floating Point Error !! |goto -Calc. 
Cls beep type Unexpected batch file error *R in line %L jexit 
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APPENDIX E: BATCH CONTROL FILE (PROJECT2.BAT) 


echo off 

CLS 

init 1 

GRAPHICS 

bat /N /p /s 

smlt EXP2 -go - -prs - -1s -ns -plm 6 -bw 


-top dynex EXP2 -in EXP2.STT -sc -ls -plm 6 -bw 
smlt EXP2 -gm - -ns -plm 6 -bw 
rep EXP2 -outf INTERVAL.OUT -t -bw >NUL 
rep EXP2 -bw >NUL 


infoofrb 1 
Call =topi 
Exit 


goto -top$*A 


-topl ФА = 1 
color \1F 
ram 
cls 


begtype 









MAIN MENU NIE 





ENSURE THAT YOU HAVE VIEWED THE STATUS REPORT 
\1Е FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION #2 


\1р 1 MF VIEW YOUR SUBSYSTEM STATUS REPORT || 









\1р 2 \1F PROCEED TO SIMULATE NEXT TIME PERIOD 


Choose an option: (DO NOT HIT «ENTER» AFTER SELECTION!!!!) ; 
end 


-lstkeyl inkey %0 | if %0 # = 1 type %0; 
if $0 - keyOlb return 
goto -%0~1 


-2ndkeyl inkey %1 | if %1 # = 1 type 5*1; 
if %1 = keyOlb return 


if %1 = key020 goto -$%0$1 
if %1 = key00d goto -$%0$1 
if %1 = key008 goto -topl 
if $1 - keyl4b goto -topl 


goto -%0%11 


-1-1 **** VIEW PROJECT STATUS REPORT *4 XR KRKKKKKKKKKKKK EK 
rep EXP2 EXP2 -outf JUNK.OUT -t -sc -1s -plm 6 -bw 
INKEY $0 
bat /p /s goto -topl 


-2-1  **** PROCEED WITH NEXT SIMULATION *****JXxx4ddk kde 
BAT CLS 
BAT COLOR MF 
BAT BEGTYPE 
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Kk k e eee oe ee eee eoe oe eee eec oc oc cce ce ee eee eoe eO eee eo x Ax x x 0000 x X x x x 


* * 
* FIRST, Determine your desired staff level alone. * 
* SECOND, Be prepared to present and defend your subsystem needs i 
* to the other manager. * 
* THIRD, When the other manager is ready, have a conference to * 
x discuss your needs. Е 
* FOURTH, You must together: * 
* * 
* 1. Agree on the desired staff levels for both subsystems. * 
X 2. Ensure that the sum of both is below the ceiling. * 
* * 
* FIFTH, Enter the desired staffing level for both subsystems * 
* into the documentation sheet. (You both do this * 
T individually) * 
* * 
x Press «ENTER? for step SIX. * 
* * 
e he e eoe eoe ee oO oe eoe coe oe oce eoe ce eoe eee oe eoe eoo eoe oe eoe oe eoe eoe ooo oo oe eoe 0 x Ax xA xA x x xx x x x 


END 
bat /p /s goto -top 


-%0-1 
-5%051 
-%0%11 beep goto -topl 


=0n. error- 


if *R > 82 if *R « 90 type 1! Floating Point Error !! |goto -Calc. 
Cls beep type Unexpected batch file error $R in line %*L |exit 
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APPENDIX F: INITIAL DATA (INIT.EXE) SOURCE CODE 


PS INIT.C - Put init info in file. */ 


#include "stdio.hn" 
#include "dos n" 
#include "ctype.h" 
#include "se.h" 


main(argc, argv) 
int argc; 

char *argv[]; 

( 


struct info userinfo; 


char logfile[FILESIZE], outfile[FILESIZE], name[30], 
smc[10]; 
FILE ЕЕ, *tobent();:; 
/* Opening formalities ... */ 
ІТ (агас<2) ( /* NO arguments entered  */ 
printf("\nNeed to know if project 1,2 or 3"); 
exit (0); 


} 


/* Get init info from screen */ 
cls (); 

set cursor (6,5); 

printf("Please enter Your Last Name"); 
set cursor (6,35); 

scanf("%s", name) ; 

set cursor(7,5); 

printf("Please enter your smc"); 
set cursor (7, 35); 

scanf ("%s", smc); 

/*printf("$s $s", name, smc) ;*/ 
_dos getdate (é&userinfo.date) ; 
strcpy (logfile, ""); 

strcat (logfile, LOGFILE); 

strcat (logfile, argv[1]); 
s"tropwv(outfile, ""y; 
strcat(outfile, OUTFILE); 
sStrcat(outfile, argv[1]); 


if((fl-fopen(logfile, "w"))-zNULL) í 
printf("\couldn’t open %s for write", logfile) ; 
exit (0); 


} 
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if((f2-fopen(outfile, "w"))-zNULL) { 
printf("NXcouldn't open $s for write", outfile); 
exit (0); 


fprintf(fl, "Nn%s %s", name, smc); 
fprintf (f2, “\nts %s", name, smc); 
fprint El "\п%а-%а-%а", userinfo.date.month, 
userinfo.date.day, \ 
userinfo.date.year) ; 
fprinc £ (6 "\п%а-%а-%а", userinfo.date.month, 
userinfo.date.day, \ 
userinfo.date.year) ; 
fclose(f1); 
folosettf2); 
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APPENDIX G: DATA STRIPPING (INFOOFB.EXE) SOURCE CODE 


/* INFOCFB.C - Read infile containing data and put it in 
outfile. 
Reads 14 lines and prints out 12 values.*/ 


#include "stdio.h" 
#include "dos.h" 
finclude "ctype.h" 
#include "se.h" 


main(argc, argv) 
int argc; 
char *argç[]; 
( 
struct info userinfo; 
char outfile[FILESIZE], name[30], smc[10], tmp[30]; 
char dat [12]; 
FILE xfi, *fo, *fopen():; 
int a 


y= Opening formalities ... */ 

if (argc<2) ( /* NO arguments entered */ 
printf("NnNeed to know if project 1,2 ог 3"); 
exit(0); 
) 

strcpy(outfile, ""); 

strcat(outfile, OUTFILE); 

strcat(outfile, argv[1]); 

if((fi-fopen(INFILE, "r"))-zNULL) { 
printf("Ncouldn't open $s for read", INFILE); 
exit(0); 
) 

if((fo=fopen(outfile, "a"))==NULL) { 
printf ("\couldn't open $s for write", outfile); 
exit(0); 
) 


/* Read line 1: Current... Elapsed time */ 
for (1=0; 1<6; 1++) { 
fscanf(fi, "ss", tmp); 
/*printf("S$s", tmp);*/ 
) 
Rscoanf(ti, "£s", dat); 
/* Write line 1 */ 
Fprintf (fo, "Nn%s ",dat); 
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/* Read line 2: Initia w l Ü Project */ 
for (1=0; 1<9; 1++) { 

fscanf(fi, 158", ТШЕШ; 

/жргіпЕет (“запор А 

) 


/* Read line 3: Project Size...Tasks*/ 
for (i20; 1<2; 1++) { 
fscant (fi, "%s", tmp); 
/* printf("$s ffirmp) 


) 
fscant (fi, "8 dat); 
fscanf (fi, "%s", tmp); 
/* Write line 3 */ 
tprintf(fo, "$8 T" dat); 


/* Read line 4: Project Duration....Days  */ 
for (i20; 1<2; 1++) ( 

fscanf (fi, "%5", tmp); 

/|*Cbrantf( rs Emp) И 

) 
£scanft (£178 "2s". cake: 
£Scant (fi, "ss jj tmp) 
/* Write line 4 */ 
fprant rt (Lopes Ves datis 


/* Read line 5: Reported...Days */ 
for (i120; 1-12; itt) { 
fscanf (fi, "%3", tmp); 
/ x" printt( sU сар) 
) 


/* Read line 6: $dev....Percent  */ 
for (i20; i«4; i++) { 

fscanf (fi; "3s"; tmp); 

|* praintf( $s" ВПР. ^^ 

) 
fscanf(fri, "2s dat); 
fscanf(fi, "$s", tmp); 
/* Write line 6 */ 
tporzntft(rto рае). 


/* Read line 7: $testing....Percent  */ 
for (1=0; 1<4; itt) { 
fscanf (fi, "%5", tmp); 
/*® printf("$s", Empi a 


} 
fscanf (fi, "%s", dat); 
fscanf (f1, "%s", tmp; 
/* Write line 7? */ 
fprint: (fo Tors aD. 
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/* Read line 8: Perceived..Size..Tasks  */ 
for (i=0; i<7; i++) { 

сеа (Е, а tmp) 

< printe: ("$s tmp) / 

} 
mecant (£1, "ss"; dat); 
fscanf(fi, "%s", tmp); 
/* Write line 8 */ 
tprintf (fo, " Ss ",dat); 


/* Read line 9: Perceived..Cost..Man Days  */ 
for (1=0; i<7; itt) { 
fscanf(fi, "%s", tmp); 
print tf ("%2s", `Ymp) ; * / 


) 
fscanf (fi, "%s", dat); 
fscanf(fi, "%s %s", tmp, tmp); 
/* Write line 9 */ 
Fprintf (fo, ""%s ",dat); 


/* Read line 10: Total Number...Staff  */ 
Бог (1=0; 1<6; 1++) { 

fscanf(fi, "%s", tmp); 

Zu roms tmp)? */ 

) 
BEScant(tr "35", dat); 
fscanf (fi, "s ws", tmp, tmp); 
/* Write line 10 */ 
БОКТОП (ТО, " %s ", dat); 


/* Read line 11: New Est of...Days  */ 
for (i=0; 1<6; 1++) { 

fscanf (fi, "%s", tmp); 

ЕАР СЪЗ Lmp);*/ 

) 
fscanf (fi, "Ss", dat); 
fscanf (fi, "%s ", tmD); 
"write line II */ 
print f (fo, " %s ", dat); 


/* Read line 12: Maximum Tolerable...Days  */ 
for (i120; i«4; i**) 4 

Бесате (Са, -“4-"” tmp); 

DN rame isi tmp); */ 

) 
fscanf (fi, "%s", dat); 
mRocant(fi, "$s", tmp); 
/* Write line 12 */ 
fprintf (fo, " $s ", dat); 


З 


/* Read line 13: Total Man...Days  */ 
for (i=0; i<4; i++) { 

fscanf (fi, "3s", empi. 

/* printf ("3s ШЕП У 

} 
fscanf (fip "Se" dat 
fscanf (fi, "%s %s", tmp, tmp); 
/* Write line 13 */ 
fprintf (fo, "~ аа 


/* Read line 14: Total No of tasks dev. to date */ 
for (1=0; i1<7; i++) { 
fscanfi(fi, "Ss", emp). 
/* pranti(' te") (eno = 


} 
fscant (fi, "ss" > dat); 
fscant (f1,. "ss", шр) 
ух Write line 14 77 
fprintf (fo; "es "7; dati, 


fclose (fi); 
fclose (fo); 
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APPENDIX H:  MULTI-PROJECT EXPERIMENT COMPUTER SCREENS 


Please enter Your Last Name HARDEBECK 
Please enter your smc 2293 


Important Points to Remember !!!]1!!]!!! 
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 


- The system will start by showing you the size of the initial core 
team (they developed the requirement specifications). It will 
then ask you for your desired staffing level for the remainder of 
the lifecycle. 

- Staffing decisions need to be coordinated with the other subsystem 
manager to ensure that the sum of the two does not exceed the 
total project work force ceiling. 

- Next, the simulation will run through the first time period (40 days) 
and provide you with a status report for your subsystem. At the end 
of each reporting period, you will have an option to revise your 
desired staff level. Make your changes to the desired staffing level 
on the documentation sheet provided as well as on the screen. 

- Keep in mind that if a work force ceiling is imposed on your 
project, the simulation will not allow the sum of the staff requests 
for the 2 subsystems to be above that ceiling. 


A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 


- GOOD LUCK! Press <ENTER> to continue. 


po 


THE 
FIRST, 
SECOND, 
THIRD, 


FOURTH, 


FIFTH, 


SIXTH, 


WORK FORCE CEILING SUM FOR BOTH SUBSYSTEMS HAS BEEN SET Al: oe 


THE SIZE OF YOUR INITIAL CORE TEAM =o. 9.0 People 


Determine your desired staff level alone. 

Be prepared to present and defend your subsystem needs to 

the other manager. 

When the other manager is ready, have a conference to discuss 
your needs. 

You must together: 


1. Agree on the desired staff levels for both subsystems. 
2. Ensure that the sum of both is below the work force ceiling. 


Enter the desired staffing level for both subsystems into the 
documentation sheet. (You both do this individually) 

Enter the desired staffing level for both subsystems into the 
Computer. Press <ENTER> to keep the current values, otherwise 
type in the new values. 


Your subsystem current staffing level = 


FIRST, 
SECOND, 


THIRD, 


FOURTH, 


FIFTH, 


SIXTH, 


Your subsystem current staffing level 


97. 


Other subsystem current staffing level 


S 


THE SIZE OF YOUR INITIAL CORE TEAM IS: 5.0 People 


Determine your desired staff level alone. 

Be prepared to present and defend your subsystem needs to 

the other manager. 

When the other manager is ready, have a conference to discuss 
your needs. 

You must together: 


l. Agree on the desired staff levels for both subsystems. 
2. Ensure that the sum of both is below the work force ceiling. 


Enter the desired staffing level for both subsystems into the 
documentation sheet. (You both do this individually) 

Enter the desired staffing level for both subsystems into the 
Computer. Press «ENTER» to keep the current values, otherwise 
type in the new values. 
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Make sure that you have written the staffing 
level decisions for both subsystems down on 

your documentation sheet before continuing 

with the simulation. 


This is your final chance to check and correct 
Staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected staffing levels and press ENTER. 


Make sure that you have written the staffing 
level decisions for both subsystems down on 
your documentation sheet before continuing 
with the simulation. 


This is your final chance to check and correct 
Staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected staffing levels and press ENTER. 


Your subsystem selected staffing level 
5. 


Other subsystem selected staffing level 
B. 


T7 


Press «ENTER» to simulate the next time interval. 


MAIN MENU 


ENSURE THAT YOU HAVE VIEWED THE STATUS REPORT 
FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION #2 


VIEW YOUR SUBSYSTEM STATUS REPORT 


PROCEED TO SIMULATE NEXT TIME PERIOD 





Choose an option: (DO NOT HIT <ENTER> AFTER SELECTION!!! !) 
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SUBSYSTEM STATUS REPORT 


ELAPSED TIME = = = = = = = = => 40 Days 
ESTIMATES MADE AT THE START OF THE PROJECT 
Subsystem Size 396 Tasks 
Subsystem Cost in Man Days 27121 Man Days 
Subsystem Duration 320 Days 
SUBSYSTEM STATUS at Time = = = = = = = = = = = => 40 Days 
Updated Estimate of Total Subsystem Size 399.38 Tasks 
% Development (Design & Code) Reported Complete 8.70 Percent 
$ Testing Reported Complete 0.00 Percent 
Updated Estimate of Subsystem Man Days т, 11.00 Man Days 
Total Man Days Expended to date 116.92 Man Days 
Updated Est. of Subsystem Duration (start-end) 278 Days 
Current Staff Size 4.0 Fulltime Staff 


ЕКЕЗ5 «ENTER» TO RETURN ТО MENU 


kkkkkkkkkkkkkkákkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 


* * 
FIRST, Determine your desired staff level alone. * 
ШІ SECOND, Be prepared to present and defend your subsystem needs E 
x to the other manager. ж 
E THIRD, When the other manager is ready, have a conference to * 
5 discuss your needs. Ж 
foe FOURTH, You must together: % 
ж ж 
* l. Agree on the desired staff levels for both subsystems. * 
E 2 SEnsure that the sum Gieboth as below the cealing. 5 
ж ж 
KELP LETH, Enter ehe desired staffing level for both subsystems ^ 
К into the documentation sheet. (You both do this * 
x individually) 5 
* * 
А Pressi ENTER- for Step SIX. T 
* * 
K k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k £ k k k k k k oe eo ok oko eco ooo k k k k k k k k k k k k k k k k k k x kx X 
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INPUT YOUR DESIRED STAFFING LEVEL 


* o ooo o oe ooo Cx 0o 0o o x 9 Xx C kx Ax Xx A A x Xx x X kx 


SIXTH, Enter the desired staffing level for both subsystems into the 
Computer. Press <ENTER> to keep the current values, otherwise 
type in the new values. 


Your subsystem current staffing level = 


5 
INPUT YOUR DESIRED STAFFING LEVEL 
хжхххжххххххххххххххххххххххххххххххх 

SIXTH, Enter the desired staffing level for both subsystems into the 


Computer. Press <ENTER> to keep the current values, otherwise 
type in the new values. 


Your subsystem current staffing level 
on 


Other subsystem current staffing level 
F 
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Make sure that you have written the staffing 
level decisions for both subsystems down on 
your documentation sheet before continuing 
with the simulation 


This is your final chance to check and correct 
Staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected levels and press ENTER. 


Your subsystem selected staffing level = 


ешь «ке өше тшш» ee oe oe oe oe = Q Ó oe om om om om oe oe we «кыс «жы» «жи» «жы» oe G we oe ЖЕ s «низ G G q олын олан анын балын «БЫ» екы» «ны» ee q oe uum Gum Gu om om om om om oe oe oe oe oe oe oe s оны: ow s «ны» «шы» 


Make sure that you have written the staffing 
level decisions for both subsystems down on 
your documentation sheet before continuing 
with the simulation 


This is your final chance to check and correct 
staffing levels for this time period. Press 
ENTER to keep the same numbers or enter 
corrected levels and press ENTER. 


Your subsystem selected staffing level 
о, 


Other subsystem selected staffing level 


—— ome ome om om om s s s «ны» «жы» «ы» «шы» «шы» S AP UU «шы» «кы» «кы» «шы» G G «жы» «ж» өм» «ж» оны ow ш ww ww ww ww G ow G s «шы» «ғы» «жы» «ыз «ныс «жы» «жы» «ны» G ое оны» «жы» «кыс «жы» оны» «ы» өл» «ы» өн» «жы» «ы» «лы» «жы» «ы» GU A «лы» «ы» a= 


Press «ENTER» to simulate the next time interval. 
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APPENDIX I: "DUMMY" EXPERIMENT DOCUMENTATION 


Dummy 
YOUR NAME 
SMC NO. 
INTRODUCTION 


The exercise you are about to undertake is similar in many ways to the 
flight simulators that pilots use to mimic flying an aircraft from takeoff 
at point A to landing at point B. Instead of flying an aircraft, though, 
this simulator mimics the life of a real software project from the start 
of the design phase until the end of testing. In this simulation, you 
will be more than an observer. In fact you will play an important role on 
the project: that of the project manager. 


Specifically, your role will be to track the project’s progress using a 
number of status reports that will be produced for you at two-month 
intervals (40 working days) during the project. As the project manager, 
you must then determine the project’s staff size based on the knowledge 
you gain from these reports. You can hire additional staff or decrease 
the staffing level as you deem necessary to complete the project. 


PROJECT 


The project that you will manage, happens to have been a real project 
conducted ina real organization. The particular organization is on the 
leading edge in software engineering technology. For the project, you 
will be given a project profile containing the following initial 
information: 


Estimated Project Size (in No. of tasks) 
Estimated Duration (in No. of Work Days) 
Estimated Project Cost (in No. of Man Days) 
Size of Initial Core Team (in No. of People) 


A task is a software module that is approximately 50 lines of code in 
size. The Core Team is the group of software professionals that developed 
the project's requirement specifications. (Remember, you are taking over 
at the beginning of the Design Phase). 


82 


YOUR TASK 


Your task is to use the bi-monthly status reports generated by the project 
team at different points in the project to determine a desired staffing 
level for the remainder of the project. Your objective in setting the 
staffing level should be to: 

(a) complete the project on schedule 

(b) at the lowest possible cost 


YOUR GRADE 
Equal weighting will be given to schedule overruns and budget overruns: 


(a) Schedule overruns are calculated as follows: Say the initial 
"Project Duration" is 200 days, and the final completion date is 240 
days, you will be considered to have overshot the schedule by 
(240-200) /200 = 20%. 


(b) Cost overruns are calculated as follows: Say the initial 
"Project Cost in Man Days" is 2,000 man days and the final cost at 
completion is 2,500 man days, you will be considered to have 
overshot the cost by (2, 500-2, 000) /2,000 = 25%. 
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SOME IMPORTANT THINGS TO CONSIDER IN MAKING YOUR STAFFING DECISIONS: 


di You will start with a core team that developed your Project's 
Requirements. This is to reflect the fact that most projects start out 
with a small core team of personnel. 


е; As a Project manager, you specify the desired staffing level for the 
remainder of the lifecycle. Of course, the actual staff levels may be 
different due to things you cannot control such as turnover and lengthy 
hiring delays. 


33 In some cases, a workforce ceiling might be imposed on the project 
(i.e., because of budgeting considerations). Your staff request must not 
exceed it. 


4. The hiring delay for new employees can take up to 6 weeks. Once new 
people are hired, the assimilation period for a newly hired employee is 
typically one month long. This is the time needed to train a new employee 
in the mechanics of the project and bring him/her up to speed. A new 
employee (i.e. one that is being trained) is only half as productive as an 
xperienced employee. 


>. The personnel turnover rate is 20% per year. 

G. Staff sizes will always be in terms of "Full Time Equivalent" 
people. 

Ja At different points in the project you will be given information on 
the status of the project. Four key pieces of information for this 


staffing task are: 


(a) The "Updated Estimate of Total Project Size" (this can change to 
reflect the addition of new requirements). 


(b) The "Updated Estimate of Total Man Days" (this update can change 
to reflect the addition of new requirements and/or changes in the 


estimate of the team’s overall productivity). It is important to 
note, that this is an estimate which may or may not be totally 
reliable. 


(c) The "Total Man Days Expended to date". Subtracting the "Total 
Man Days Expended to date" from "Updated Estimate of Total Man Payer 
yields the "Remaining Effort in man days." 


(d) The "Updated Est. of Project Duration (start-end)". In order to 
determine the "Remaining Time", you subtract the "Elapsed Time" from 
the "Updated Est. of Project Duration (start-end)." It is important 
to note, that this is an estimate which may or may not be totally 
reliable. 
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B Let us say that at some point in the project the "Remaining Effort" 
is 1000 man days, the "Remaining "Time is 100 days and you have 7 full 
time equivalent employees working. You are, thus, in a position where you 
have to use your judgement to do one of the following: 


йе, Stick with the current schedule. If so then you will need a 
staff size of 1000/100 = 10 full time employees. 


2 Stick with your staff size of 7. This means the schedule has 
to be pushed back. In this case the model will make the appropriate 
adjustment to the schedule for you. That is extend it to 1000/7 = 
143 man days. 


Six Do a bit of both. That is increase the staff size a bit, say 


to 8, which will also mean that the schedule will be extended 
(appropriately by the model) to 1000/8 = 125 days. 
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HOW TO PLAY THE GAME 


1. 


Take some time to practice and get familiar with the system. 


(a) Do not start the network. From the C> prompt chande 
directories to CD IS4300A. 


(b) Type DUMMY for running the dummy project. 


(c) The system will show you the size of the initial core team. 
It will then ask you for your initial desired staffing level. 


(d) Determine your desired staffing level for the remainder of the 
lifecycle. 

(e) Ensure that your request does not exceed the workforce 
ceiling. 

(t) Input your desired staffing level on your documentation sheet. 
(а) Enter the staff level number into your PC. 

(h) Next the simulation will run through the first simulation time 


period and show you the "MAIN MENU". 


(I) Press 1 to view the status report. DO NOT HIT ENTER AFTER 
MENU SELECTIONS. Please be sure you understand the report. 


(3) Perform steps (d) thru (h), for as many intervals as necessary 
(by pressing 2), till you are comfortable with the system. Run the 
dummy project for a minimum of 2 intervals. 


(k) After you are finished, hit «ESC» when you are at the "MAIN 
MENU" screen to exit. This is the only time you should hit <ESC>. 
(1) Turn your disk and documentation sheet in to the lab 
attendant. 


86 


DUMMY 


Management’s Initial Project Estimates 


Initial Estimate of Project Size: 396 Tasks 
Initial Estimate of Project Cost: 1,111 Man Days 
Initial Estimate of Project Duration: 320 Days 
Size of Initial Core Team: 5 People 


A project is considered complete when "% Reported Complete" = 100 for both 
development work (i.e., Design and Coding) and testing. 


Staffing Level Sought 

Please enter your staffing decisions below: 
At start of Simulation: 

Time elapsed - 40 days: 


Time elapsed - 80 days: 


Time elapsed - 120 days: 
Time elapsed - 160 days: 
Time elapsed - 200 days: 


Time elapsed - 240 days: 


Time elapsed - 280 days: 
Time elapsed - 320 days: 
Time elapsed - 360 days: 
Time elapsed - 400 days: 
Time elapsed - 440 days: 
Time elapsed - 480 days: 
Time elapsed - 520 days: 
Time elapsed - 560 days: 
Time elapsed - 600 days: 
Time elapsed - 640 days: 


*** WHEN YOU ARE DONE, CALL FOR A LAB ATTENDANT RUN = 


В 


APPENDIX J: "PROJECT 2" EXPERIMENT DOCUMENTATION 
Project:2 

YOUR NAME 

PARTNER'S NAME 
INTRODUCTION 


The exercise you are about to undertake is similar in many ways to the 
flight simulators that pilots use to mimic flying an aircraft from takeoff 
at point A to landing at point B. Instead of flying an aircraft, though, 
this simulator mimics the life of a real software project from the start 
of the design phase until the end of testing. In this simulation, you 
will be more than an observer. In fact you will play an important role on 
the project: you are the manager of one of the two major subsystems that 
are being developed on this project. The other subsystem is managed by 
another manager. 


Specifically, your role will be to track the progress on your subsystem 
using a number of status reports that will be produced for you at two- 


month intervals (40 working days). As the subsystem manager, you must 
then determine the staff size for your subsystem. You can increase your 
staff size or decrease it as you deem necessary. In making these 


decisions, though, you will need to coordinate with the other, subsystem 
manager since the sum of your staffing needs must not exceed the project’s 
total staff ceiling. 


PROJECT 


You and the other subsystem manager will be given a project profile 
containing the following initial information: 


Estimated Size for each Subsystem (in No. of tasks) 
Estimated Duration for each subsystem (in No. of Work Days) 
Estimated Cost for each subsystem (in No. of Man Days) 
Size of Initial Core Team on each subsystem (in No. of People) 
Subsystem size will be in terms of tasks. A task is a software module 
that iS approximately 50 lines of code in size. The Core Team is the 
group of software professionals that developed the subsystem’s requirement 
specifications. (Remember, you are taking over at the beginning of the 


Design Phase). 
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YOUR TASK 


Your task is to use the bimonthly status reports generated by your 
subsystem team to determine a desired staffing level for your subsystem. 
Your objective in setting the staffing level should be to: 

(a) complete your subsystem on schedule. 

(b) at the lowest possible cost 
And remember, in determining your staffing needs, you will need to 
coordinate with the other subsystem manager since the available staff 
might not be enough for both of you. 


YOUR GRADE 
Your "Compensation" as a manager will be based on: 


l. How effective you are in delivering your subsystem on schedule 
and on budget (or as close to on schedule and on budget as possible) 


2. How close was the project as a whole (i.e., the two subsystems) 
delivered on schedule and on budget. 


You will notice that initially both subsystems will be scheduled to end 
together. The total project's final completion date (which of course will 
depend on the performance of yourself as well as the other subsystem 
manager) will be the date at which the later of the two subsystems 
finishes. As for the project's final total cost, it will simply be the 
sum of the costs of the two subsystems. 


Equal weighting will be given to schedule overruns and budget overruns: 


(a) Schedule overruns are calculated as follows: Say the initial 
"Subsystem Duration" is 200 days, and the final completion date is 
240 days, you will be considered to have overshot the schedule by 
(240-200) /200 = 20%. 


(b) Cost overruns are calculated as follows: Say the initial 
"Subsystem Cost in Man Days" is 2,000 man days and the final cost at 
completion is 2,500 man days, you will be considered to have 
overshot the cost Бу (2,500-2,000) /2,000 - 25%. 


*& K K K K K k k k k * * K * *  * £ £ £ & & & £ & & £ & & & £ & £ *  &  *  * * £ K * £ K * * * * * £ £ £ * * * K * £ £ * * £ K * x X * 


* 
* IMPORTANT = 
* * 
* 80% of your compensation will be based on your subsystem's ж 
* performance. x 
* 20% of your compensation will be based on total project = 
E performance. x 
* * 
3 * k k K * * eoe eoo e foe ooo k k eoe eoe eoe eoe eoe eoe eoe eoe e efe eee eee eoe eoo oo oo e oe x x A x x X fx 
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SOME IMPORTANT THINGS TO CONSIDER IN MAKING YOUR STAFFING DECISIONS: 


к You will start with a core team that developed your subsystem's 
Requirements. This is to reflect the fact that most projects start out 
with a small core team of personnel. 


Ze As a subsystem manager, you specify the desired staffing level for 
the remainder of the lifecycle. Of course, the actual staff levels may be 
different due to things you cannot control such as turnover and lengthy 
hiring delays. 


з In some cases, a workforce ceiling might be imposed on the project 
as a whole (i.e., because of budgeting considerations). The sum of your 
Staff request and that of the other subsystem manager must not exceed it. 


4. The hiring delay for new employees can take up to 6 weeks. Once new 
people are hired, the assimilation period for a newly hired employee is 
typically one month long. This is the time needed to train a new employee 
in the mechanics of the project and bring him/her up to speed. A new 
employee (i.e. one that is being trained) is only half as productive as an 
experienced employee. 


S The personnel turnover rate is 20$ per year. 

6: Staff sizes will always be in terms of "Full Time Equivalent" 
people. 

ТЕ At different points in the project you will be given information on 
the status of the project. Four key pieces of information for this 


staffing task are: 


(a) The "Updated Estimate of Total Subsystem Size" (this can change 
to reflect the addition of new requirements). 


(b) The "Updated Estimate of Subsystem Man Days" (this update can 
change to reflect the addition of new requirements and/or changes in 


the estimate of the team's overall productivity). It is important 
to note, that this is an estimate which may or may not be totally 
reliable. 


(c) The "Total Man Days Expended to date". Subtracting the "Total 
Man Days Expended to date" from "Updated Estimate of Subsystem Man 
Days" yields the "Remaining Effort in man days." 


(d) The "Updated Est. of Subsystem Duration (start-end)". In order 
to determine the "Remaining Time", you subtract the "Elapsed Time" 
from the "Updated Est. of Subsystem Duration (start-end)." It is 
important to note, that this is an estimate which may or may not be 
totally reliable. 
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8. Let us say that at some point in the project the "Remaining Effort" 
is 1000 man days, the "Remaining "Time is 100 days and you have 7 full 
time equivalent employees working. You are, thus, in a position where you 
have to use your judgement to do one of the following: 


E: Stick with the current schedule. If so then you will need a 
staff size of 1000/100 = 10 full time employees. 


дір Stick with your staff size of 7. This means the schedule has 
to be pushed back. In this case the model will make the appropriate 
adjustment to the schedule for you. That is extend it to 1000/7 - 
143 man days. 


ЗЕ Do a bit of both. That is increase the staff size a bit, зау 


to 8, which will also mean that the schedule will be extended 
(appropriately by the model) to 1000/8 = 125 days. 
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ШЕ; 


HOW TO PLAY THE GAME 


The real simulation starts now. 


(a) Insert the disk you are given, and enter a commands from the 
A» prompt. 

(b) Type PROJECT2. 

(c) The system will show you the size of the initial core team. 


It will then ask you for your initial desired staffing level. 


(d) Determine your desired staffing level for the remainder of the 
lifecycle, but do not enter it yet. Prepare yourself to discuss 
your needs and coordinate with the other manager. 


(e) Confer with the other manager. The objective here is to 
ensure that the sum of both your requests does not exceed the 
workforce ceiling. If it does, you must both work out a compromise. 


(Е) When you agree on staff levels that together are within the 
workforce ceiling, input both yours and the other managers desired 
staffing levels on your documentation sheet. Each of you does this. 


(g) Enter both numbers into your PC (i.e., each of you would enter 
both numbers individually). 


(h) Next the simulation will run through the first simulation time 
period and show you the status report for your subsystem only. You 
should not show your status report to the other manager, nor should 
you try to see his/her's. 


(1) Perform steps (с) thru (g), for as many intervals as 
necessary, till your subtask is complete. That is when "% reported 
complete" = 100% for both development work (i.e., Design and 


Coding) and testing. 


(3) If the other subsystem manager finishes his/her subtask before 
you, you still must continue until you finish yours. In this case, 
you make your staff decisions alone, and just enter a zero for the 
other subsystem. 


(k) There is no need to turn in the documentation sheet after each 
interval of a project. However, A LAB ATTENDANT MUST VERIFY YOUR 
FINAL RESULTS at the completion of THE project. Call a lab 
attendant as soon as you are done with the project. 
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Initial Estimates 


Initial 
Initial 
Initial 
Srze of 


PROJECT 2A 


Your Subsystem Other Subsystem 


Estimates of Size: 396 Tasks 475 Tasks 
Estimates of Cost: 1,111 Man Days 1,345 Man Days 
Estimates of Duration: 320 Days 320 Days 
Initial Core Teams: 5 People 5 People 
A subsystem is considered complete when "$ Reported Complete - 100 for 


both development work 


(i.e., Design and Coding) and testing. 


Staffing Level Sought 


Enter staffing decisions: 


YOUR SUBSYSTEM OTHER SUBSYSTEM 


At start of Simulation: 


Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 
Time 


Time 


Final Cost in Man days 
Final Duration in days 


*** WHEN YOU ARE DONE, 


elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 
elapsed 


elapsed 


40 days: 
80 days: 
120 days: 


160 days: 


200 days: 
240 days: 
280 days: 
320 days: 
360 days: 
400 days: 
440 days: 
480 days: 
520 days: 


560 days: 


(sum of both subsystems) 


(for later subsystem) 


CALL FOR A LAB ATTENDANT кк 


ОЗ 


APPENDIX K: 


Initial Estimates 


Estimates of 
Estimates of 
Estimates of 
Initial Core 


Iniciar 
Initial 
Initial 
Size of 


A subsystem is considered 


both development work (1.e. 


Staffing Level Sought 
Enter staffing decisions: 


At start of Simulation: 


Time elapsed - 40 days: 

Time elapsed - 80 days: 

Time elapsed - 120 days: 
Time elapsed - 160 days: 
Time elapsed - 200 days: 
Time elapsed - 240 days: 
Time elapsed - 280 days: 
Time elapsed - 320 days: 
Time elapsed - 360 days: 
Time elapsed - 400 days: 
Time elapsed - 440 days: 
Time elapsed - 480 days: 
Time elapsed - 520 days: 
Time elapsed - 560 days: 


Final Cost in Man days 
Final Duration in days 


**^* WHEN YOU TARE DONE, 


"PROJECT 2" 





DOCUMENTATION SHEET (PLAYER B) 
PROJECT 2B 


Your Subsystem Other Subsystem 


Size: 475 Tasks 396 Tasks 
Cost: 1,345 Man Days 1,111 Man Days 
Duration: 320 Days 320 Days 
Teams: 5 People 5 People 
complete when "$ Reported Complete - 100 for 


, Design and Coding) and testing. 


YOUR SUBSYSTEM OTHER SUBSYSTEM 


of both subsystems) 


later subsystem) 


ххх 


FOR A LAB ATTENDANT 
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APPENDIX L: SAMPLE POPULATION RANDOMIZING WORKSHEET 
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APPENDIX M: "PROJECT 2" EXPERIMENT PAIRS 


E Ti pane к ЕЕЕ 
= 
жт 


SEGMENT 2 


TEAM ` 
PLAYER A 
BREWER 
BOXALL 
WAWRZENIAK 
CARNEY 
CLARK 


ШЕТ 


STEFFENSEN RAUSCH 


ESPIRITU TRIMBLE 
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SEGMENT 1 
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SEGMENT 2 


PLAYER A 
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|. INDIVIDUAL 
| PLAYER B 
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APPENDIX N: SEATING CHART 
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STAFFING LEVEL DECISIONS 
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APPENDIX P: 


Bryant 2604 


5-30-1991 

40 475 1,345 
80 475 1,345 
120 475 1,345 
160 475 1,345 
200 475 1,345 
240 475 1,345 
280 475 1,345 
320 475 1,345 
360 475 1,345 
379 475 1,345 


X-BRYANT 2604 


8-15-1991 

40 475 1,345 
80 475 1,345 
120 475 1,345 
160 475 1,345 
200 475 1,345 
240 475 1,345 
280 475 1,345 
320 475 1,345 
360 475 1,345 
B79 475 1,345 


HARKLEROAD 2621 


5-30-1991 

E396 1,111 
80 396 1,111 
1209396 1,111 
160 396 1,111 
200 396 1,111 
ОЛО 396 1,111 
280 396 1,111 
320 396 1,111 
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SAMPLE DATA VALIDATION RUN 
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oroo i 11) 00132 982 2600401 
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100.00 100.00 1,723.64 1,723.06 291 6. 
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69.58 0.00 1,375.30 852.59 233 6.7 
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KORAK 
BREWER 
BOXALL 
WAWRZENIAK 
CARNEY 
DITRI 
STEFFENSEN 
ESPIRITU 
FORTIN 
ZOLLA 
STRAND 
BRYANT 
BOOTH 
BANNICK 
VOBORIL 
MONTGOMERY 
LASKOWSKI 
CLARK 
RAUSCH 
TRIMBLE 
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REPEAT1.DAT 


1 APPLEGATE AI SUE S то с 00 8.00 9.00 8.00. 6.50 3.00 
2 RAMSEY AI И .. ОО. 00 8570084. 80 4.70 4.70 5.30 
4 TENAN AI "uer Ug Oo. 60 76-80 500959 009 3. 90:7 3. 50 
5 RODGERS AI он тес а есес 50 800 7.50 6.50 
6 FRANK AI euo UD EC 0086.00 5. 006.00 6.00 5.00 
7 HAAS AI uS 0E 50" 7-50. 5.9509 550.5500. 5.00 
8 VANMETER Al 5.00 4.00 4.00 4.00 4.00 4.00 4.00 4.00 
9 BRIEDE AI ООУ ОО ДУОЮ «4095557009 5500825 950. 5.50 
10 PATRICK AI о. аа Б 3072 5,50 
12 BRADY AI СОО GG 20 7300558550. 6.00 25. T0NES C50 74.50 
25 MCKEON AT pum UU. 620908 7. 00. 7-000572 -00 7.00 
26 GRIMES AT ОСОО ООО ОО ОИЕ ОООО ОО 6:00 —4 750. 5,00 
27 WRIGHT AT О 75350 69-00 6:00 6.00906 290 4:50 
28 HARKLEROAD AT ОРОО ООУ У ООЗУ ОО n200. 7300 007.9016. 00 
29 KORZYK AT ОЕ ТОО 5.50 4.90. 4.80- 5.20 «6-00 76. 00 
30 BREWER AT 2-30 4.50 4.50 4.50 5.00 5.50 5.50 
31 BOXALL AT SUME 00 ОООО 7.00 7.00 7:00 7.00 
32 WAWRZENIAK AT ОЕЕО О ТЕО 700 Е 600 7 8:00 72987090. 58-00 
35 STEFFENSEN АТ ле опы 53,00 аа 905 0-0 00 
ECSESPIRI TU AT ООО ОО бео 88:095 7.50 5.00 5.04.00 
REPEAT2.DAT 
ЕШ СЕТТГЕМҮЕК ВІ А ПО О. 00 7900 —8.50 12.00 
14 RHEAD BI ие ОО Ве 0035 50 15.00-97.00 8.00 79.70 
ICSCOLER BI Е Ss 5.70. 5.70. 6250: 6.00 5.50 
17 SALITSKY BI SENSN SE SUIES SOM S309 5.50 7200) 7.50 :8.50 
i SOUTH ВТ CUO tor UUM СОИ 69000 5290 7.00 9. 001000 
19 LORENTZEN BI Бе ое Об. 00: «4.50 5.50 10.00 10.00 
ZUSHILI BI ООО ОО ЕС 00 6.00 76:00 6.00 6.50 7.50 
21 BAREFIELD BI DESIT SU: 7x50 7.00 6.50. 6.50. 6.50 
22 HOCHSTETLER BI ORRE SOTE оро 7.00 (7,00 7.00 7.00 7/00 
24 MANNING BI OO О EO GTO B80 7220 9250 10:50 
ЕП ЕОКТІМ ET ОЕЕО Шо 900^ 7.00. 90-7500» 7.00 
38 ZOLLA BT РБС 09, э 00 5.00 9.00 10:50 20.00 
39 STRAND BT DM S1. 505 72000 T2300 7.00. 28.50. 9.00 
40 BRYANT BT GC 008 ООУ СОВ 2900 78700 8.00 8.00 5.00 
41 BOOTH BT ПОР ТОП X609 76900 7. то 9.007 9.00 
42 BANNICK BT ӨШ ТТТ 90 Z 7 00777 00: 67.00 8.00 5.90 
43 VOBORIL BT 200005 77:90 77 209.7600. 7.002 7:00: 7.00 
44 MONTGOMERY BT СПОР 6.000 82005 7200 .7.00.- 7.00 - 8.50 
47 RAUSCH BT ОООО СООКО о ооо 00. 10.00 10.00 10.00 
48 TRIMBLE BT S005 5000 ЗОО 5: 0099600 8.00 10.00 10.00 
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APPENDIX R:  SAS CONTROL FILES 


libname dataname "c:\sas\saswork\"; 
data dataname.dat; 

infile "c:\sas\saswork\AR.DAT"; 

input NUMBER 1-2 NAME 5 4-15 GROUP $ 17-18 COST 20-26 SKED 28-30; 

INICOSTA=1111.00; 

TNISREDA=320; 

DIFFCOST= (COST—INICOSTA) /INICOSTA; 

DIFFSKED= (SKED—INISKEDA) /INISKEDA; 

COSTSKED= (DIFFCOST+DIFFSKED) /2; 

lust; 
proc means; 

Var DIFFCOST DEPP SkKED- 

by GROUP; 

title ‘Statistics for Player A Comparison’; 
Proc glim 

class GROUP; 

model DIFFCOST DIFFSKED=GROUP ; 

manova h=GROUP / printe printh; 

title ‘Multivariate ANOVA of Player A’; 
proc anova; 

classes GROUP; 

model COSTSKED=GROUP; 

title ‘Cost + Sked ANOVA for Plaver A’; 
run; 
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libname dataname "c:\sas\saswork\"; 
data dataname.dat; 
infile "c:\sas\saswork\BR.DAT"; 
input NUMBER 1-2 NAME $ 4-15 GROUP $ 17-18 COST 20-26 SKED 28-30; 
INICOSTB=1345.00; 
INI SKEDB=320; 
DIFFCOST-(COST-INICOSTB)/INICOSTB; 
DIFFSKED- (SKED-INISKEDB)/INISKEDB; 
COSTSKED= (DIFFCOST+DIFFSKED) /2; 
115%; 
proc means; 
var DIFFCOST DIFFSKED; 
by GROUP; 
title 'Statistics for Player B Comparison’; 
proc glm; 
class GROUP; 
model DIFFCOST DIFFSKED=GROUP ; 
manova h=GROUP / printe printh; 
title 'Multivariate ANOVA of Player B'; 
proc anova; 
classes GROUP; 
model COSTSKED-GROUP; 
title 'Cost + Sked ANOVA for Player B'; 
RAI 
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libname dataname "c:\sas\saswork\"; 
data dataname.dat; 

infile "c:\sas\saswork\XR.DAT"; 

input NUMBER 1-4 TEAM $ 6-26 GROUP $ 28 COST 30-36 SKED 38-40; 

COMBCOST=2456.00; 

COMBSKED=320; 

DIFFCOST= (COST—COMBCOST) /COMBCOST; 

DIFF SKED=(SKED—COMBSKED) /COMBSKED; 

COSTSKED= (DIFFCOST+DIFFSKED) /2; 

USt; 
proc means; 

ECURODIRPFCOST DIEPSKED; 

by GROUP; 

title 'Statistics for Combined Comparison'; 
Emoc glm; 

class GROUP; 

model DIFFCOST DIFFSKED=GROUP; 

manova h=GROUP / printe printh; 

title '’Multivariate ANOVA of Combined Data’; 
proc anova; 

classes GROUP; 

model COSTSKED=GROUP; 

title ’Cost + Sked ANOVA for Combined Data’; 
Тїп; 
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libname GRADES "C:\SAS\SASWORK\"; 
data GRADES .DAT; 
infile "C:\SAS\SASWORK\GRADES.DAT"; 
input NUMBER 1-2 NAME $ 4-15 GROUP1 $ 17 GROUP2 $ 20 GRADE 23-25; 
Erst; 
proesprint; 
title 'Multiproject Management Experiment'; 
title3 'Sample Population'; 
title5 'Grade Data Set'; 
proc means; 
var GRADE; 
by GROUPI; 
title 'Statistics for Individual vs Team Comparison t 
title3 'Based on Grade Data'; 
proc anova; 
classes GROUPI; 
model Grade-GROUPI; 
title 'Grade ANOVA for Individual vs Team'; 
proc Sort; 
by GROUP2; 
proc means; 
var GRADE; 
by GROUP2; 
title ‘Statistics for Player A vs Player B Comparison 
title3 'Based on Grade Data'; 
proc anova; 
classes GROUP2; 
model GRADE=GROUP2; 
title 'Grade ANOVA for Player A vs Player B'; 
run: 


libname dataname "c:\sas\saswork\"; 
data dataname.dat; 

infile "c:\sas\saswork\REPEAT1.DAT"; 

input NUMBER 1-2 NAME $ 4-15 GROUP $ 17-18 T1 22-26 T2 28-32 T3 
34-38 

Т4 40-44 Т5 46-50 T6 52-56 Т7 58-62 Т8 

64-68; 

Tist; 
proc. glm 

class GROUP; 

model T1-T8-2GROUP; 

repeated TIME / SHORT SUMMARY PRINTE; 

title.’ STAFFING LEVEL DECISIONS'; 

title3 ‘Repeated Measures for AI verses АТ”; 
run: 
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libname dataname "c:\sas\saswork\"; 
data dataname.dat; 

infile "c:\sas\saswork\REPEAT2.DAT"; 

input NUMBER 1-2 МАМЕ $ 4-15 GROUP $ 17-18 T1 22-26 T2 28-32 T3 
34-38 

T4 40-44 T5 46-50 T6 52-56 T7 58-62 T8 

64—68; 

lust; 
proc glm; 

class GROUP; 

model T1-T8-2GROUP; 

repeated TIME / SHORT SUMMARY PRINTE; 

title 'STAFFING LEVEL DECISIONS'; 

title3 'Repeated Measures for BI verses BT'; 
DD 
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